-
Notifications
You must be signed in to change notification settings - Fork 448
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
google-http-java-client
being used by storage library logs partial access tokens.
#1705
Comments
We took a look and it turns out that it is not related to auth library as it does not set log levels for HttpRequests. We also verified that with default settings auth data logs only with Level == ALL: The issue seems to be that certain loggers like sl4j get misconfigured by default. Probably logger initialization need improvements to support some popular loggers better. |
Also, the access_token with dots referred above as partial - is actually a full access_token. It is a Google thing to have access_token with trailing dots.. They are fine and accepted back by Google as is. https://stackoverflow.com/questions/68654502/why-am-i-getting-a-jwt-with-a-bunch-of-periods-dots-back-from-google-oauth |
The offending line of code is here.
Problem
If you are authoring a Java module which uses the cloud storage client library under the hood, access tokens are always logged to the console appender by default.
This affects JAR modules distributed by a Maven like repository, or places where console applications are used but the module does not necessarily have full control on the calling context. For e.g. GitHub actions.
When running the module, you can see log messages that look like:
Note: The partial access token visible:
ya29.c.b0AXv0zTOyVPYZ45W_cQIypBveTXRoQDlSjg53C_6KXvTWKcATx8uEgLqymqPI3xv_IboLmCijXUt9r2UxFml72hqCC_Qm6m06gXdBDE1oAcxL93c05U2B2PTDeKPbOGYb3BjJt33Radqn0ym-5nSzy5UdQHtjR-VZdYRtgCZ2mTzs2sMq_fXD5rhPar1pgA-9sSwnnmqQD9VCvh-LlTPWG_25V2ONcNiRr-YK.....
Current Workaround
Apps, that want to disable all logging of requests have to use a delegating
HttpRequestInitializer
by doing something like:While this works, this approach needs to be duplicated when multiple client libraries are involved.
Ideal Solution
The client library should provide the library to control request level logging. Ideally all client libraries using the same http-client should respect the log-level. We should also only log errors by default.
The text was updated successfully, but these errors were encountered: