cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6573) AccessToken doesn't serialize with snake-case
Date Fri, 04 Sep 2015 09:35:45 GMT

    [ https://issues.apache.org/jira/browse/CXF-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14730563#comment-14730563
] 

Sergey Beryozkin commented on CXF-6573:
---------------------------------------

Sure, I thought you had a standalone OAuth2 container/server on a separate port, something
we demo too, and which would likely require a SSO solution (SAML SSO or OIDC RP - we have
some decent support for these though some tuning may be needed for the latter) - unless you
do not rely on the authorization grant but only on the grants that require no human user signing
in.
 
If you have OAuth2 services collocated with the application services then it can still be
better to have a dedicated jaxrs:endpoint specifically for OAuth2 AccessTokenService - in
which case OAuthJsonProvider will just be a single provider. It is def faster because it is
not using the reflection - though the saving is probably 1ms given that the token response
are very small, unless the encryption is involved... If you use a single Application (no Spring,
etc) - then yes you can't have multiple endpoints created so I see why you may need to have
both providers on a single endpoint (but note a single CXF JAXRS servlet can be initialized
with multiple Applications should you need it, or may have have multiple servlets).

When you have  OAuthJsonProvider and Jackson on a single endpoint and ClientAccessToken -
both providers return true from isWriteable, both providers are typed by Object, but OAuthJsonProvider
is more specific with its Produces(application/json) as opposed to a wildcard value in Jackson
- hence OAuthJsonProvider wins. It is in the spec in the section on selecting MBW. I have
to admit this is not 100% robust - should Jackson (or other provider) also have Produces(application/json)
then we'd have 2 absolutely equal candidates on a single endpoint and the selection process
will not be predictable - if it will happen in the future then we can just introduce typed
OAuthJsonProvider, example, OAuthJsonProvider<ClientAccessToken> - this will win.
I'm actually still thinking of experimenting with JAXB annotations and have a test with a
CXF Jettison based provider - we can configure it to drop 'parameters' with a stax transformation
feature. Will also document about OAuthJsonProvider asap

 



> AccessToken doesn't serialize with snake-case
> ---------------------------------------------
>
>                 Key: CXF-6573
>                 URL: https://issues.apache.org/jira/browse/CXF-6573
>             Project: CXF
>          Issue Type: Wish
>          Components: JAX-RS Security
>    Affects Versions: 3.1.2
>            Reporter: Karl von Randow
>            Priority: Minor
>
> The org.apache.cxf.rs.security.oauth2.common.AccessToken class doesn't declare and JAXB
(or other) annotations to influence how it is serialized. So it uses the default serialization
style of the JAXB context.
> In my case this is camel case.
> This means that the AccessToken response from the AccessTokenService uses camel case.
The OAuth docs _appear_ (I'm not a scholar of them) to indicate that it should be snake case.
> Is that true? Is this a thing? Would it be something you'd consider, adding `@XmlElement(name
= "token_key")` annotations? That would be a breaking change for existing users...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message