OK, I've just committed it to the main trunk. It should be on maven in a
few hours.
Martin
On 10.5.2011 23:34, Wise, Jeffery R (Jeff) wrote:
> Martin,
> 1) Like - I haven't implemented an OAuthProvider yet, so compatibility
> is not my concern. My only concern is potential confusion between the
> usage of OAuthConsumer.getPrincipal(), isInRole() vs
> OAuthToken.getPrincipal(), isInRole(). You'll need some good
> documentation around that.
> 2) Dislike - I don't like method arguments that have different meaning
> in different contexts. Also, you'd have to avoid consumerKey and
> token collisions.
> 3) Dislike - Even without a token, we still need access to the role
> information.
> Thanks again.
> Jeff
>
> ------------------------------------------------------------------------
> *From:* Martin Matula [mailto:martin.matula_at_oracle.com]
> *Sent:* Tuesday, May 10, 2011 3:55 PM
> *To:* users_at_jersey.java.net
> *Subject:* [Jersey] Re: 2-Legged OAuth
>
> 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