-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[MonologBridge] Added SwitchUserTokenProcessor to log the impersonator #37704
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
[MonologBridge] Added SwitchUserTokenProcessor to log the impersonator #37704
Conversation
862ad2b
to
3ea8997
Compare
Hello, Thanks for your first contribution. I like a lot your idea 👍🏼 Thanks. I have a question about the implementation : Why did you choose the create two Processor instead of doing all the work in the existing processor? |
I have added the second processor in order to separate processing of tokens. In my opinion, tokens should be processed by their own processors. Moreover, some projects may not use user impersonation feature, and an abstract processor provides the ability to easily implement your own processor |
*/ | ||
protected function getKey(): string | ||
{ | ||
return 'original_token'; |
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 know it's the legacy naming, but I don't really like original_token
which kind of misses some context. What about impersonating_token
or impersonator_token
instead?
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 have used the original_token
key because of the original (impersonator) token's getter has name getOriginalToken
. As for me, the impersonator_token
key is more suitable, but I am not sure that is a good idea to change the original_token
key to impersonator_token
until the original token's getter is renamed to getImpersonatorToken
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.
As someone looking at the logs or Sentry reports for instance, impersonator_token
is more meaningful than original_token
though. The internal name in the code does not matter in this regard.
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 can rename
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 would use impersonator_token
.
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.
Changed to impersonator_token
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.
LGTM (apart from the renaming of the key)
*/ | ||
protected function getKey(): string | ||
{ | ||
return 'original_token'; |
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 would use impersonator_token
.
885a1d7
to
2f8651d
Compare
Thank you @IgorTimoshenko. |
This pull request adds the ability to log the impersonator user in case of user impersonation feature usage. The current TokenProcessor logs only the current token and there are no ability to simply log the original token, so we need to copy-paste the TokenProcessor and change a few lines to log the original token