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