-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
Clients are not challenged when they are expected to be #10
Comments
@nuxwin Just a question: are you aware of the Unfortunately, we don't have a UI for when that flag is enabled, which means you would then need to manually create the rules when you want to whitelist anything. However, it seems like it might fit the needs you're indicating. Originally posted by @weierophinney at zfcampus/zf-mvc-auth#106 (comment) |
Sure, but you forgot that authorization always comes after authentication and thus, the clients are always challenged (e.g. in case of http basic,digest authentication). That our main problem here. You can set as many autorization rules as you want, the problem will remain same as long as we will not make the authentication layer aware of public resources. To resume, this assertion For your sentence about the UI, we could add that ;) Originally posted by @nuxwin at zfcampus/zf-mvc-auth#106 (comment) |
A simple solution which would solve all problems would be to apply authorization rules, even if an authentication adapter returns a response. In such specific case, the authorization listener could just override the response (status code and headers) if after all the I'll provide some patches and tests for this. Originally posted by @nuxwin at zfcampus/zf-mvc-auth#106 (comment) |
Working on this ATM, implementing a map which will allows to enable authentication on specific routes. Originally posted by @nuxwin at zfcampus/zf-mvc-auth#106 (comment) |
@weierophinney
My #92 fix was wrong after all... It prevent challenge of clients when needed...
The problem coming from the #92 fix
Now, let's imagine the following scenario: A client requests the following URI
https://host.tld/API/VERSION1
(here, the matching authentication type isbasic
). NoAuthorization
header is sent by the client.Then, the following will occurs in the default authentication listener:
basic
)At this point, if the mvc http adapter don't find the
Authorization
header, it will simply return aGuestIdentity
. So, later on, the authorization listener will simply set a 403 status code ifGuestIdentity
is not allowed to access the resource.The problem that the #92 fix tried to solve
Currently, the authentication layer don't known if a resource is private or public. That layer only know which authentitcation type is available for a specific API.
Thus, current design (assuming that the fix referenced by #92 is reverted) involve challenging clients, whatever the resource is private or not. This means here that an API is just either public or private. There is no concept of public and private resources at this level.
This is bad because if someone want provide both public and private resources through the same API, it cannot because clients (even for public resources) will be challenged. That was the point of my #92 fix that is wrong because it delegate challenge phase to the authorization layer, which is only able to send 403 status code. This is normal because the authorization layer must not be concerned about authentication.
A way to resolve that problem would be to allow the developer to mark specific resource as public (no authentication required). Now here, we have to think how. We are currently mapping API/VERSION to authentication type only. We should maybe add another map allowing to mark specific resource as public. This would involve matching of the controller, action and method.
Originally posted by @nuxwin at zfcampus/zf-mvc-auth#106
The text was updated successfully, but these errors were encountered: