Seems you are right. Would it work for you if I relax the token checking
in the filter? If the token is not present, the security context would
not be set, since the principal and roles are associated with the token.
Is that fine with you?
Martin
On 10.5.2011 20:48, Wise, Jeffery R (Jeff) wrote:
> Martin,
> Looking at the OAuth 1.0 spec (http://tools.ietf.org/html/rfc5849), I
> see a couple of places where it mentions the access token as
> optional. Take a look at the definition of the oauth_token parameter
> in section 3.1. Also, take a look at the 3rd bullet under section
> 3.2. Is this a missed requirement in the OAuthServerFilter, or do
> you interpret it differently?
> Thanks.
> Jeff
>
> ------------------------------------------------------------------------
> *From:* Martin Matula [mailto:martin.matula_at_oracle.com]
> *Sent:* Tuesday, May 10, 2011 3:34 AM
> *To:* users_at_jersey.java.net
> *Subject:* [Jersey] Re: 2-Legged OAuth
>
> Jersey supports OAuth 1.0, which does not have a notion of 2-legged
> OAuth. And OAuth 2.0 is still a work in progress.
> You can easily implement 2-legged OAuth by issuing the access token
> and token secret together with consumer key and consumer secret when
> the consumer registers (i.e. it will be 2-legged, but using 4
> credentials instead of 2). This is the correct way, does not violate
> OAuth 1.0 and is supported by Jersey. E.g. twitter does it this way
> (provides access token and token secret representing you in case you
> want to access it in a 2-legged way).
> Would that work for you?
> Martin
>
>
> On 10.5.2011 0:04, Wise, Jeffery R (Jeff) wrote:
>> The OAuthServerFilter appears to only support 3-legged OAuth as it
>> requires an access token. Does Jersey support 2-legged OAuth from a
>> provider perspective, or do I need to write a stripped down version
>> of the OAuthServerFilter to support 2-legged OAuth?
>> Thanks.
>> Jeff