-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Panic (recovered) when client secret is nil due to filters #6933
Comments
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 To address this issue, you have a couple of options:
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:
These references should help you navigate the issue and apply the most suitable solution for your setup. This comment was generated by Glime. |
Hello, seems similar to #6932 that I just reported earlier today: issue parsing client_secret in the configuration file |
It's unrelated to that issue. The issue is they have not configured a secret because they are using the |
Well, tangentially related it seems. If you're using the expand-env filter which were likely to deprecate then you need to quote every 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. |
A misconfigured client can potentially throw a nil panic which is recovered but undesirable. This fixes that issue. Fixes #6933 Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
Version
v4.38.2
Deployment Method
Docker
Reverse Proxy
Traefik
Reverse Proxy Version
No response
Description
The Authelia panicked when the OIDC client configured a malformed
client_secret
. Specifically, when using$plaintext$xx
inclient_secret
in the configuration file and wrongly enabling theexpand-env
filter at the same time.Reproduction
client_secret
in OIDC client and enableexpand-env
Expectations
The Authelia is expected to exit when checking the configuration at startup.
Also, when using hash ( e.g.,
$pbkdf2-sha512$310000$...
) forclient_secret
, Authelia won't panic but complains that the client is using an incorrect secret. This may confuse since the problem is theexpand-env
filter explains theclient_secret
value silently. Checking at startup may improve useability in this scenario.Configuration (Authelia)
Build Information
Logs (Authelia)
Logs (Proxy / Application)
No response
Documentation
No response
Pre-Submission Checklist
I agree to follow the Code of Conduct
This is a bug report and not a support request
I have read the security policy and this bug report is not a security issue or security related issue
I have either included the complete configuration file or I am sure it's unrelated to the configuration
I have either included the complete debug / trace logs or the output of the build-info command if the logs are not relevant
I have provided all of the required information in full with the only alteration being reasonable sanitization in accordance with the Troubleshooting Sanitization reference guide
I have checked for related proxy or application logs and included them if available
I have checked for related issues and checked the documentation
The text was updated successfully, but these errors were encountered: