[
https://issues.apache.org/jira/browse/OLTU-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14905114#comment-14905114
]
Stein Welberg commented on OLTU-12:
-----------------------------------
Good question. I haven't done anything with this since may 2013.. I also
haven't send Ben an email.
However, I wonder whether we should solve this issue since it's quite a corner
case if an access token is supplied in two ways. I would actually strongly
recommend to only use the header method and deprecate the other two since they
are less secure. The spec also states that you MUST support the authorization
header approach and might support the other two methods.
> [oauth2-resourceserver] resource access validation always fails if there is
> more than one parameter style defined
> -----------------------------------------------------------------------------------------------------------------
>
> Key: OLTU-12
> URL: https://issues.apache.org/jira/browse/OLTU-12
> Project: Apache Oltu
> Issue Type: Bug
> Reporter: Ben Noordhuis
> Assignee: Stein Welberg
> Attachments: AMBER-15-adding-test-patch.txt, amber15.patch
>
>
> Why? Because the headers, body and query validators are tried in turn in
> OAuthAccessResourceRequest.validate(). Two of the validators will throw and
> the second exception is re-thrown unconditionally outside the loop.
> I'm not sure what the right approach here is. I wrote a preliminary patch[1]
> but one edge case is that a request with a 2.0 query token and 1.0
> authorization header will slip through[2].
> Checking for OAuthError.TokenResponse.INVALID_REQUEST doesn't work either.
> BodyOAuthValidator always throws that when the request isn't
> application/x-www-form-urlencoded (i.e. almost all the time).
> [1] https://github.com/bnoordhuis/amber/commit/b4df9c2
> [2] curl -v -H 'Authorization: OAuth
> abc123,oauth_signature_method="HMAC-SHA1"'
> http://localhost:8080/?oauth_token=abc123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
