[
https://issues.apache.org/jira/browse/HTTPCLIENT-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286374#comment-17286374
]
Michael Osipov commented on HTTPCLIENT-2138:
--------------------------------------------
bq. I understand your concern with wire/packet. To elaborate on my use case, I
would like to ship a jar with HttpClient as a dep to other users, and I won't
have control over how they choose to configure their log4j.
You can't be serious, cant you? You NEVER impose any kind of logging
configuration on the client. This is fundamentally broken design. It is at the
complete descretion of the client when, where and how logging is done.
One possible way is to use SLF4J markers to tag log events: {{SENSITIVE}},
{{HEADER}}, {{BODY}}. A Logback Filter/TurboFilter can handle that. Can't tell
for Log4J2.
> Debug Log level logs sensitive information
> ------------------------------------------
>
> Key: HTTPCLIENT-2138
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2138
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient (classic)
> Reporter: Cyrus Vafadari
> Priority: Minor
>
> When I enable debug level logging, I see
> ```
> [2021-01-20 18:02:35,862] DEBUG http-outgoing-0 >> Authorization: Basic
> <CREDENTIALS_APPEAR_HEAR_IN_BASE64> (org.apache.http.headers:139) [2021-01-20
> 18:02:35,884] DEBUG http-outgoing-0 >> "Authorization: Basic
> <CREDENTIALS_APPEAR_HEAR_IN_BASE64>[\r][\n]" (org.apache.http.wire:54)
> [2021-01-20 18:02:35,899] DEBUG http-outgoing-0 << " <title>Unauthorized
> (401)</title>[\n]" (org.apache.http.wire:54)
> ```
> If agreed, I can open a PR to mask secrets in the debug log. If that makes
> the log less useful, I can at least make this configurable, since in my case
> it is a security violation to have any secrets whatsover in the logs
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]