-
-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[Security] Add ability for authenticators to explain why they didn’t support a request #60538
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
Conversation
a175f93 to
b0cdff7
Compare
| * Add support for closures in `#[IsGranted]` | ||
| * Add `OAuth2TokenHandler` with OAuth2 Token Introspection support for `AccessTokenAuthenticator` | ||
| * Add discovery support to `OidcTokenHandler` and `OidcUserInfoTokenHandler` | ||
| * Add ability for authenticators to explain why they support the request or not |
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.
| * Add ability for authenticators to explain why they support the request or not | |
| * Add ability for authenticators to explain why they do not support the request |
If they support it, no reason is set, right?
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.
s/does/do
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.
Updated, thanks
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.
If they support it, no reason is set, right?
I was not sure if the userland could benefit from it, but since it is only displayed when the authenticator doesn’t support the request let’s not advertise it indeed.
12f9679 to
cc4097b
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
541085e to
66af8a6
Compare
nicolas-grekas
left a comment
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.
Nice :)
I'm just wondering about the name. What about RequestDecision instead?
Why not; then what about
|
|
It'd say $requestDecision and $decisionReasons. |
It wouldn’t serve any purpose in the current state of this PR but yes. The problem I have with |
|
$requestDecisionReasons? |
f4ade34 to
0cecef5
Compare
|
Fine by me; just pushed the changes. |
0cecef5 to
9bdf856
Compare
nicolas-grekas
left a comment
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.
One more iteration :)
| class RequestDecision | ||
| { | ||
| public bool $support; | ||
| public ?bool $lazy = null; |
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.
when is this used? what could be built with that?
| public ?bool $lazy = null; | |
| public bool $isLazy; |
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 planned to use this class for firewall listeners.
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.
Oh, so let's remove it from this PR and add it in the one about listeners then.
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.
Should the TraceableAuthenticator set them then?
| if ($this->supports === false) { | ||
| $requestDecision->support = false; | ||
| } else { | ||
| $requestDecision->support = true; | ||
| $requestDecision->lazy = null === $this->supports; | ||
| } |
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.
| if ($this->supports === false) { | |
| $requestDecision->support = false; | |
| } else { | |
| $requestDecision->support = true; | |
| $requestDecision->lazy = null === $this->supports; | |
| } | |
| $requestDecision->isSupported = false !== $this->supports; | |
| $requestDecision->isLazy = null === $this->supports; |
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 think isLazy should stay null if the request is not supported.
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.
the decision was not lazy, so why?
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.
Cause lazy only makes sense if the request is supported.
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.
BTW it is not the decision which is lazy but the request support; not sure about this naming then 🤔
f7520a5 to
50a70cb
Compare
50a70cb to
0d12051
Compare
|
I'm not sure it is worth complicating the authenticator API for this debug purpose. Complex setups involving many authenticators are pretty rare as opposed to voters, and logs work pretty well for this. |
0d12051 to
0f2834d
Compare
|
I do think this would be useful whatever the number of configured authenticators. And isn’t one of the profiler’s interest avoiding to scan the logs? 😁 |
0f2834d to
5dcb9ec
Compare
|
Sure. It's a matter of balance and I feel like it's not worth it here 🤷 Maybe it's only me, let's see what others think. ping @wouterj |
5dcb9ec to
0e1ee99
Compare
Inspired by #59771 this PR allows authenticators to advertise why they didn’t support a request by passing a new
RequestSupportargument to theirsupportsmethod. Calling itsaddReasonmethod will cause the profiler to display them:If this is accepted, this will pave the way for firewall listeners to expose informations about their calls to
supports(this is why theRequestSupportclass also holds$resultand$lazyproperties) andauthenticate, thus closing #36668.