Ah, right. That was a dumb attempt :)
Here are some options I could implement:
1) break compatibility, add getPrincipal() and isInRole() to Consumer
interface, use that when no token is provided
2) do a workaround of calling OAuthProvider.getAccessToken(consumerKey)
in case the token is missing - you could return a token implementation
which returns null from the token secret and whatever you need from
getPrincipal() and isInRole()
3) set principal to consumerKey, isUserInRole() would always return false
I think I'll go with 1). Any comments?
Martin
On 10.5.2011 21:42, Wise, Jeffery R (Jeff) wrote:
> Martin,
> Without the principal set, how would I know whether the request had
> been authenticated? Wouldn't it look just like a request without any
> OAuth headers/parameters present?
> Thanks.
> Jeff
>
> ------------------------------------------------------------------------
> *From:* Martin Matula [mailto:martin.matula_at_oracle.com]
> *Sent:* Tuesday, May 10, 2011 2:22 PM
> *To:* users_at_jersey.java.net
> *Subject:* [Jersey] Re: 2-Legged OAuth
>
> 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