[
https://issues.apache.org/jira/browse/CXF-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905732#comment-13905732
]
Sergey Beryozkin commented on CXF-5569:
---------------------------------------
Using ALLOWED_OAUTH_PARAMETERS to filter out the unrecognized parameters can
only affect the signature calculation if it is a form request and if some
filters in front of CXF (perhaps Spring Security, etc) have moved the form
parameters inti the request map, I can't imagine the other scenario for now.
The spec is OK with including the form parameters into the signature
calculation, though I'd say the HAWK scheme makes it neater, where the body
hash is optionally included to avoid any ambiguities.
I've updated the code to allow for the unrecognized parameters only if it is a
form payload and the check is lax (default is true); the spec specifically
talks about the form payloads in this regard.
Can you please experiment with 2.7.11-SNAPSHOT ?
> OAuth AbstractAuthFilter and query parameters used for signing
> --------------------------------------------------------------
>
> Key: CXF-5569
> URL: https://issues.apache.org/jira/browse/CXF-5569
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS Security
> Affects Versions: 2.7.10
> Reporter: Jason Klapste
> Priority: Minor
> Fix For: 3.0.0-milestone2, 2.7.11
>
>
> In the AbstractAuthFilter the query (or body) parameters used for signing are
> only those included in ALLOWED_OAUTH_PARAMETERS.
> But if I'm reading the RFC correctly, it looks are though ALL parameters
> should be considered for signature generation.
> To support both backwards compatibility, can I suggest exposing the
> ALLOWED_OAUTH_PARAMETERS to subclasses (either directly or via
> getter/setters) along with a flag that can be set to automatically include
> any and all parameters?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
