-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Prevent log spamming when using a non-cached JWKS #8730
Conversation
Multiple auth providers (keycloak, firebase, ...) do not allow caching on their JWK endpoints. In this case, Hasura requests the endpoint every second. This change avoids spamming the logs when this happens. See hasura#8299
Beep boop! 🤖 Hey @lovasoa, thanks for your PR! One of my human friends will review this PR and get back to you as soon as possible. Stay awesome! 😎 |
Hi @lovasoa, thanks for the patch! This seems benign but there are definitely use cases where users might want to see these logs at INFO level too. We think it might be more prudent to make this configurable, so that you can customize it for yourself as needed, as outlined in #8611. I see you've already spotted this issue. Would you be interested in submitting a patch along those lines? |
Hi, and thanks for the response :) |
It really depends on the caching proposed by the auth provider. I took a look at a few (Auth0, AWS Cognito, Firebase) and they all seem to encourage some caching. The Firebase documentation I found suggests that keys are cached, and uses a central, public keyset. I hit the URL, https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com, and got the following headers back:
Can you explain your situation in greater detail so I can understand why it's different? |
Hey @SamirTalwar , I'm sorry I missed your message when you posted it. Thank you for investigating on this !
Unfortunately, that does not seem to be configurable, and we end up with very large amounts of logs from hasura, which are expensive to store and make debugging more difficult. |
That's interesting. My first thought was that we should probably let the auth provider specify the expiry, but a default of 1 second seems very arbitrary. I'll bring this up and see if we can make that configurable. |
Thank you @SamirTalwar ! |
Beep boop! 🤖 Hey @lovasoa! Sorry that your PR wasn’t merged. Do take a look at any of the other open issues to see if you’d like to take something up! We’re around on Discord if you have any questions 😄 |
Great, thank you @pranshi06 ! |
Multiple auth providers (keycloak, firebase, ...) do not allow caching on their JWK endpoints.
In this case, Hasura requests the endpoint every second.
This change avoids spamming the logs when this happens.
Description
Changelog
CHANGELOG.md
is updated with user-facing content relevant to this PR. If no changelog is required, then add theno-changelog-required
label.Affected components
Related Issues
#8299
Limitations, known bugs & workarounds
Does this PR add a new Metadata feature?
run_sql
auto manages the new metadata through schema diffing?run_sql
auto manages the definitions of metadata on renaming?export_metadata
/replace_metadata
supports the new metadata added?GraphQL
Breaking changes