On 17/06/13 16:53, inteloid wrote:
Thank you Sergey, I really enjoy the speed you reply with :-).
may happen only when I have a vague idea of what I'm talking about :-)
For this case the if AccessTokenValidatorService holds instances of
ServerAccessToknes inside it's memory it becomes a single point of failure,
so there's a need to persist the tokens somewhere.
Sure. persist them in DB, with ehcache, etc, up to OAuthDataProvider, I
was not suggesting they have to be kept in memory
To keep it simpler, isn't there a way to use the standard OAuthRequestFilter
filter and implement a serializable ServerAccessToknes token which will be
fetched and saved by OAuthDataProvider used by aforementioned filter?
Yes, in the example I pointed you to the filter actually have no any
knowledge of access tokens, what it gets from AccessTokenValidator is a
JAXB beab, AccessTokenValidation - this is nearly a copy of
ServerAccessToken. AccessTokenValidationService will return
AccessTokenValidation over HTTP (by asking its data provider first),
but as I said this is just one option: your custom AccessTokenValidator
does not even have to use AccessTokenValidationService, you can employ a
different mechanism for fetching the tokens from the remote locations
Cheers, Sergey
--
View this message in context:
http://cxf.547215.n5.nabble.com/OAuth2-for-redundant-CXF-REST-Services-tp5729365p5729384.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
