-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Redacting sensitive data with BaseUri #141
Conversation
@@ -180,7 +179,7 @@ public function withPort(Stringable|string|int|null $port): AuthorityInterface | |||
}; | |||
} | |||
|
|||
public function withUserInfo(Stringable|string|null $user, #[SensitiveParameter] Stringable|string|null $password = null): AuthorityInterface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd definitely keep the attribute for things that are clearly secrets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My issue is currently I feel that we are using a half solution. If we keep the attribute then we should IMHO put it everywhere as to completely hide the password part which is what I did now on the master branch, the couter-argument to that is that it makes accessing most of the API in logs a bit more complex only to hide the password. If we keep it only on some method but not on all method then we are not hiding the component as it will be shown completely in a full trace because internal methods do not use the Attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if I understand it correctly you are OK with the attribute in the public API where the parameter is clearly defined ... and we should not bother wth internal calls ?
Co-authored-by: Niklas Keller <[email protected]>
This feature is postponed |
see #140 for context