Panic (recovered) when client secret is nil due to filters about authelia

[james-d-elliott]

Well, tangentially related it seems. If you're using the expand-env filter which were likely to deprecate then you need to quote every $ per the known limitations in the docs: https://www.authelia.com/configuration/methods/files/#expand-environment-variable-filter

We still shouldn't panic here even though it's recovered, but we'll make sure this is fixed and link it to the issue.

Further discussion about the issue that is not directly related to the panic can be had here: #6934

Due to the fact the panic is gracefully recovered the classification of the priority of this is now low.

[glime-ai]

Please note this response was created using generative AI leveraging previously available information from the repository. This information may be helpful however it is our strong recommendation that you carefully consider the information before blindly applying it.

---

Based on the detailed description and reproduction steps you've provided, it seems like the issue arises from the interaction between the expand-env filter and the way client_secret is handled when it's prefixed with $plaintext$. The expand-env filter is designed to expand environment variables in the configuration, but when it encounters the $ symbol in the client_secret, it might be attempting to interpret it as an environment variable, leading to unexpected behavior or errors.

To address this issue, you have a couple of options:

1. Avoid Using expand-env with Sensitive Secrets: If your configuration relies on plaintext secrets, consider not using the expand-env filter for those specific secrets. This would prevent the filter from misinterpreting the $ symbol as an environment variable.

2. Use Hashed Secrets: As mentioned, using hashed secrets (e.g., $pbkdf2-sha512$310000$...) is a more secure practice and avoids the issue with the expand-env filter. Authelia supports hashing client secrets, which not only enhances security but also circumvents the problem you're encountering.

3. Check for Updates or Patches: Given that this behavior could be considered unexpected, it's worth checking if there have been any updates or patches to Authelia that address this specific interaction. The Authelia team might have recognized this as a bug and provided a fix in a newer version.

4. Report the Issue: If after trying the above solutions the problem persists, and you believe this behavior is not intended or could be handled better, consider reporting it to the Authelia team. Given the detailed information you've already compiled, this would be valuable feedback for them.

For generating hashed secrets, you can refer to the Authelia documentation on generating client secrets, which provides guidance on creating secure, hashed secrets for use in your configuration.

Documentation References:

• Generating a Random Alphanumeric String: Authelia FAQ on Generating Client ID/Identifier
• Generating a Random Password Hash: Authelia FAQ on Generating Client Secrets
• Handling of expand-env filter and its limitations: Authelia Configuration Methods

These references should help you navigate the issue and apply the most suitable solution for your setup.

This comment was generated by Glime.

[NeoXTof]

Hello, seems similar to #6932 that I just reported earlier today: issue parsing client_secret in the configuration file

[james-d-elliott]

It's unrelated to that issue. The issue is they have not configured a secret because they are using the expand-env filter but didn't quote the $ causing a panic which we should be checking much earlier.