You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Jacky Wang (JIRA)" <ji...@apache.org> on 2009/02/02 14:07:59 UTC
[jira] Created: (SHINDIG-897) Add 3-legged OAuth validation support
for RESTful api
Add 3-legged OAuth validation support for RESTful api
-----------------------------------------------------
Key: SHINDIG-897
URL: https://issues.apache.org/jira/browse/SHINDIG-897
Project: Shindig
Issue Type: Improvement
Components: RESTful API (Java)
Reporter: Jacky Wang
Priority: Minor
RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-897) Add 3-legged OAuth validation support
for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacky Wang updated SHINDIG-897:
-------------------------------
Attachment: supports-3-legged-oauth-validation.patch
Thanks for the comments, Cassie! I updated the patch according to them.
Item #1: done. only checks userID part if it's 2-legged OAuth.
Item #2, I've put some validation code in SampleOAuthDataStore.java since:
a) The validation logic uses SimpleOAuthValidator actually, and this might be replaced by the implementor if they want to have more complex control like token expiration etc.
b) This validation process links tightly with OAuthDataStore thus it might be a bit cleaner if we put them together, rather than create more interfaces, etc.
Item #3: It seems the OAuthHandler family shares pretty much code/interfaces. How about we delegates their differences on the underlying OAuthDataStore interface, which could be modified by implementors? For example, different getConsumer() implementation for all anonymous consumers. Just my 2 cents.
Item #4: Echo Cassie's idea. Although there's a reference implementation for OAuth provider on their code base, it still might be some easier for debugging and deploying if OAuth could be integrated in Shindig's code base. And it also might help future unregister oauth 3-legged supporting as well.
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669940#action_12669940 ]
Jacky Wang commented on SHINDIG-897:
------------------------------------
Hi Paul,
Thanks for your comments! =)
The current version supports 2-legged OAuth validation which leaves "token" and "token_secret" parts empty.
Basically I'm trying to add the 3-legged validation for it. Only the validation is implemented, but "where/how the token is issued" (in which login/authorization happens) is leaved out of the graph (and I'm working on that too. :D).
Your description on what this change has done is pretty precise and very clear. Sorry for my poor documentation and thanks for your clarification! =)
I found the idea "Many containers will have more granular permissions than 'hasAppInstalled()', which this change seems to favor explicitly. " is very interesting and insightful --- actually, comparing with other authentication handlers like URLParameter, such ACL (whether an app is okay to access a user's profile/friend list, etc.) is controlled in the implementation of 3 OpenSocial abstract services (people/activity/appdata). Therefore for unifying, we'd rather don't check whether user has installed this app in the AuthenticationHandler logic --- just leave it to the 3 services instances. On the other hand, if a user granted an app in the OAuth authorization process, this permission should be recorded in the underlying ACL mentioned above.
In short, we won't check "hasAppInstalled()" any more, neither in 2-legged OAuth nor 3-legged one.
I'm still cleaning the code according to your comments, and I'll post the patch asap.
Thanks! =)
- Jacky
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674541#action_12674541 ]
Paul Lindner commented on SHINDIG-897:
--------------------------------------
Thanks Jacky -- Glad to have your thoughtful work going in on this.
I've round tripped this through the hi5 implementation at http://sandbox.hi5.com and it seems like we're on the right track. The OAuthData model is a good fit to the data model we already have for applications, so consumer mapping was pretty easy. Storing tokens in memcache was also easy. A couple of ideas:
* Make OAuthEntry a full bean. This would allow it to be used more easily in JSP context.
* Add a method to get the absolute expiration time of a token/OAuthEntry -- this makes it easier when storing tokens in a cache (like Memcache)
* Consider replacing the ConcurrentHashMap in SampleOAuthData with an instance of ehCache so that we can test tokens expiring from the data store.
* Consider standardizing on some property fields in the OAuthConsumer based on metadata in the App XML. description, icon, and thumbnail come to mind.
I'd be happy to help get these done.
Cheers.
Paul
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674535#action_12674535 ]
Paul Lindner commented on SHINDIG-897:
--------------------------------------
Hi.. Just checked in some cleanups, incorporating some of Jacky's patch.
We now have an authorization UI flow that works and allows you to specify the userId in the sample implementation.
One can also override the authorization action by changing values in shindig.properties
more to come...
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Lindner resolved SHINDIG-897.
----------------------------------
Resolution: Fixed
Fix Version/s: trunk
no big issues, with this. marking resolved.
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Fix For: trunk
>
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674534#action_12674534 ]
Jacky Wang commented on SHINDIG-897:
------------------------------------
Thanks Paul! You move really fast! =)
Actually Cassie and me had some discussions on this OAuth implementation's architecture, here's the summary - Cassie, please correct me / add more details. :)
The whole things might include 3 layers:
[Layer 0: authentication handlers] 2-legged OAuth / 3-legged OAuth / unregistered OAuth (future)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Layer 1: interface, handles logical check-in, check-out, markAsAuthenticated, etc. functionality] as OAuthService
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Layer 2: storage specific, flatten standard OAuth* classes into DB rows "OAuthEntry"] as OAuthDataStore
The layer 0 is undoubtedly necessary. The reason why we separated 3 kinds of handlers is: although they could share some common code/flow, the container implementer might also want to have the flexibility to enable some of them (like 2-legged OAuth) and disable the remaining ones (like 3-legged one and unregistered one).
For the ACL (hasUserInstalledApp) issue, finally we came to the same idea that leaving it there in OAuthTwoLeggedAuthenticationHandler. It might be some comments followed to reminder the implementer taking care of the ACL check either there or in underlying opensocial handlers. On the other hand, adding the checking in OAuth handler is an additional benefit and won't harm those "underlying ACL" anyway.
It might also be helpful to abstract the layer 1 out as an interface. I suggest we still using OAuth* classes in the interface, thus the upper layer (handler) will not need to wrapper them -- the boundary of each layer might be much clear.
We're not quite sure whether the layer 2 should be abstracted out since it stands a bit closer to the implementation detail. But it could be very useful if we encapsulate the flatten code (OAuthConsumer -> consumerKey, consumerSecret; OAuthAccessor -> userId, consumerKey, token, tokenSecret, isAuthorized, type, issueTime, etc.) into an utility class thus container implementers could use them.
Finally we could end up with following classes:
== Authentication / Validation ==
[Level 0] OAuthTwoLeggedAuthenticationHandler, OAuthThreeLeggedAuthenticationHandler
(authentication classes, call OAuthService for data)
[Level 1] OAuthService, SampleOAuthService
(translates from OAuthEntry to the OAuthAccessor stuff that you need using the OAuthDataStore.)
[Level 2] OAuthDataStore, SampleOAuthDataStore
(classes to access OAuth storage)
OAuthEntry
(class modeling a row in DB)
== 3-legged OAuth granting ==
SampleOAuthServlet, SampleUnregisteredOAuthServlet
(classes look close to what Cassie has right now except as much oauth code as possible is pulled into OAuthUtil etc. to benefit containers with their own impls)
OAuthUtil
(a util class that does basic validation of messages, can verify request tokens etc etc)
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-897) Add 3-legged OAuth validation support
for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacky Wang updated SHINDIG-897:
-------------------------------
Attachment: (was: add-3-legged-oauth.patch)
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Chris Chabot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669977#action_12669977 ]
Chris Chabot commented on SHINDIG-897:
--------------------------------------
Just as a possible-interesting-reference point, when I was implementing OAuth support in the PHP version I ran into many of the same questions, whitelisting, hasApp restrictions, etc ... there's a lot of things a container could want to check on, depending on their internal policy and the amount of solar radiation that day.
So instead of trying to support every possible mutation of oauth checks, I just simplified the interface to "Hey here is some OAuth stuff, do something with it and return an OAuthToken if your cool with it, and otherwise return NULL".
In less nonsense code this would mean:
if (queryParams['oauth_signature'] is set) {
token = OAuthConsumerService->getSecurityToken(oauth_consumer_key, xoauth_requestor_id, oauth_signature) // parse the oauth fields, or just let your oauth server class deal with it
if (token == null) {
complain_loudly();
}
// continue as normal, we now have a valid OAuthSecurityToken, which also has the normal getAppId, getViewerId, etc etc
} else {
// do normal Security Token stuff
}
This does mean the pressure of implementation is on the container, however it's consistent with our SPI assumptions (we also say "getPerson(FOO)' and let the container deal with the details if it wants to or not and under what conditions).
Paul: The UI for the OAuth workflow is a container affair, you'll probably need to read up a bit on OAuth I'm affraid. Basically a 3 legged oauth consumer pokes the container asking to get a request key and redirection URL (to the container), once redirected to the container and the end-user clicking the 'I grant access' link, you upgrade the request token into an access token, and return it to the requestor, which can then be used for all subsequent requests (so the access token remains valid until the end-user revokes it)
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674847#action_12674847 ]
Cassie Doll commented on SHINDIG-897:
-------------------------------------
One change that I think definitely needs to be pulled in is the removal of consumerSecret from OAuthEntry. If you've got all this code in progress Paul it should be very easy. The only place that fetches the field, OAuthAuthenticationHandler, should change to look like this:
String consumerSecret = store.getConsumer(entry.consumerKey).consumerSecret;
OAuthAccessor accessor = new OAuthAccessor(new OAuthConsumer(null, entry.consumerKey,
consumerSecret, provider));
Pulling some of the servlet code into a Util class is probably a good task for later. That way containers can get some benefit without having to be locked into the servlet setup.
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670011#action_12670011 ]
Paul Lindner commented on SHINDIG-897:
--------------------------------------
thanks Chris and Jacky, good comments. I'll start looking into the UI components and how we might make that easier for the implementor.
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-897) Add 3-legged OAuth validation support
for RESTful api
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cassie Doll updated SHINDIG-897:
--------------------------------
Attachment: alternativeOAuth.patch
I've attached an alternative implementation Jacky. Please have a look and then lets see how to combine our code. Differences in mine:
- I included the example OAuth servlet which turns Shindig into an actual oauth provider. (btw - i did not pull up the methods it uses in SampleOAuthDataStore to the interface because people shouldn't use the servlet without modifying it to fit their own container better)
- To me, the oauth library's java objects seem very bulky and unwieldy for simple things like data storage (like OAuthConsumer, OAuthAccessor etc) and have replaced all of that stuff with a simple OAuthEntry and a string map for consumer secrets. hopefully this will make things clearer for implementers of the library
- I combined the two OAuth services like you mentioned
- in practice, i'm not sure anyone ever needs anything besides the simpleoauthvalidator because they can implement any container specific auth checking within other calls... someone speak up if you do want to override the validator though. (i just think the validator apis are so hard to understand at a first glance that it's nice to execute them in common code)
Please let me know what you think!
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674536#action_12674536 ]
Jacky Wang commented on SHINDIG-897:
------------------------------------
I'm wrapping up the related code and will post some new code to this issue asap.
Thanks! =)
- Jacky
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-897) Add 3-legged OAuth validation support
for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacky Wang updated SHINDIG-897:
-------------------------------
Attachment: supports-3-legged-oauth-validation.patch
Supports validation for 3-legged OAuth.
This patch includes:
1. Remove the "hasUserInstalledApp()" logic from OAuthConsumerRequestAuthenticationHandler - this ACL function is delegated to the implementation of underlying 3 OpenSocial services.
2. Modify OAuthLookupService to expose only 1 API "getSecurityToken" that verifies the coming OAuth request and generates the security token if it's valid. The real validation work is delegated to a new OAuthDataStore interface, which is injected when SampleContainerOAuthLookupService initialized. This delegation model is consisted with PHP Shindig's.
3. Define OAuthDataStore as API (and its implementation SampleOAuthDataStore) to handle all OAuth consumer/accessor/token issues. This API should be easily fitting-in as an OAuth provider's facility.
2-legged OAuth validation has been tested against OpenSocial-Client Java Lib (http://opensocial-java-client.googlecode.com).
3-legged OAuth one has been tested against a reference implementation (http://term.ie/oauth/example/client.php).
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674577#action_12674577 ]
Jacky Wang commented on SHINDIG-897:
------------------------------------
Thanks Paul! :)
I'm reading your code now~ =)
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674609#action_12674609 ]
Jacky Wang commented on SHINDIG-897:
------------------------------------
Hi Paul,
Just went through the code -- actually through "svn diff -r 744758 > ../r744758.patch", there're pretty many check-ins. =)
The code looks great. :)
Some thoughts:
* Consider changing the name of 2-legged OAuth handler and 3-legged one --- maybe we could call them OAuthThreeLeggedAuthenticationHandler etc straightforwardly.
* It seems like we could add some "write-back" logic to OAuthDataStore since:
a) Some OAuth extension needs to modify the OAuthAccessor and store it, and it might be not so flexible to write specific functions for each extensions.
b) New OAuthConsumer may need to be added into OAuthDataStore.
* Although I'm still thinking that OAuthEntry exposed too many low level details, like accessor layout, token, etc to the upper classes like OAuth###Handlers, it's also okay to me that take OAuthEntry as a "serialized" OAuthAccessor....
* For item 2, 3, 4 you mentioned, it seems like to be an okay solution to have a OAuthUtil class which hide all implementation details of OAuthAccessor<->OAuthEntry but only gives the "logical" functionality like "isAuthorized", "isExpired", "getAuthorizorID" etc etc.
just my 2 cents. :)
Cheers,
Jacky
However, I still have
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673767#action_12673767 ]
Paul Lindner commented on SHINDIG-897:
--------------------------------------
I modified Cassie's patch a bit and committed that code. I was able to get the PHP client talking to the URL endpoints defined in the service.
I took out the consumer secret generator hack and moved that to canonicaldb.json. I also added a number of methods to the OAuthDataStore which abstract the state changes required for the OAuth dance.
With a little work we can make the OAuthServlet work for any conditions, we just need to delineate a pass off to the native authentication/authorization UI flow and provide a callback handler for return from that.
This change also seems to break the samples project, I'm going to commit this and start clean and see if that fixes it.
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669670#action_12669670 ]
Paul Lindner commented on SHINDIG-897:
--------------------------------------
Hi Jacky,
3-legs, nice! very exciting.
Can you write up what you changed? Also, since this is a new interface we'll expect people to implement I think we should have some better documentation (and yes, I know the old interface didn't have any either..)
Let's see if I understand what you've done.
* Replace OAuthLookupService with GadgetDirService
* Replace SampleContainerOAuthLookupService with SampleGadgetDirOAuthService
* GadgetDirService adds: userHasAppInstalled(), getAppId(), getDomain(), getContainer(), removes thirdPartyHasAccesstoUser() and
* Add new Interface OAuthService with methods getConsumer() and getAccessor();
* Add samplecontainer version of OAuthService
Initial thoughts:
* Many containers will have more granular permissions than 'hasAppInstalled()', which this change seems to favor explicitly.
* My OAuth-fu is weak, how do you implement the UI for login/authorization?
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670222#action_12670222 ]
Jacky Wang commented on SHINDIG-897:
------------------------------------
Thanks Chris and Paul for your comments. :)
Totally agree with Chris's idea: the container might have a lot of things to check according to their internal policy. We'd like to offer an architecture thus easily replacement/modification of the building block could fulfill their requirement.
My possible solution is most likely the same as Chris's: the OAuthAuthenticationHandler part only validates that "this request is a valid OAuth request, either 2-legged or 3-legged", but it won't do ANY internal policy based ACL check on this request. All the ACL check will be delegated to 3 underlying SPI.
On the other hand, since the resources (profile/friendlist, etc.) is granted explicitly by user in the 3-legged OAuth process, such internal policy based ACL check needs to be short-circuited. The desired logic is listed as following:
// <<< pseudo-code starts here.
result = preparing_return_values(...)
if token.type is 3-legged-OAuthToken:
// by-pass the internal ACL check and return
return result
else:
// apply internal policy based ACL for URLParameter token and 2-legged OAuth token
if ACL.check(...) is Okay:
return result
else:
complain_loudly(); // steal from Chris's example --- Chris, please complain loudly. =)
// >>> pseudo-code ends here.
However, it seems the current OAuthToken couldn't distinguish whether it's generated by 3-legged one or 2-legged one.
Thus my proposal (though a bit too detailed) is:
1. in OAuth authorization stage, add (appUrl, userId) short-circuited rule to global ACL.
2. in RESTful SPI function, the ACL check could be unified to:
// <<< pseudo-code starts here.
result = preparing_return_values(...)
if global_ACL.check(...) is Okay:
return result
else:
complain_loudly()
// >>> pseudo-code ends here.
Just my 2 cents. :)
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-897) Add 3-legged OAuth validation support
for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacky Wang updated SHINDIG-897:
-------------------------------
Attachment: add-3-legged-oauth.patch
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674960#action_12674960 ]
Paul Lindner commented on SHINDIG-897:
--------------------------------------
Okay, latest code removes consumer secret from OAuthEntry.
I also improved error handling and used the problem reporting guidelines established here: http://wiki.oauth.net/ProblemReporting
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671248#action_12671248 ]
Cassie Doll commented on SHINDIG-897:
-------------------------------------
Overall, I think this patch is a step in the right direction, but there are still some things we should fix here:
1. the xoauth_requestor_id is not a required field for 3 legged oauth. For 3 legged oauth tokens are user specific just because that is how oauth works. So, when the token is validated by a backing store, that store should be able to tell you who the third party app is, who the user who owns the token is, and what access the token has.
2. Anything in the Sample* directory is meant to be a sample only. We recommend that that code is not really desired for reuse etc etc. You have put some generic OAuth validation code into SampleContainerOAuthLookupService. I think that code should be pushed up to the AuthHandler (or something else not in the sample dir) because all containers can use it equally well.
3. It might be cleaner to put 3 legged support and 2 legged support into 2 different oauth handlers. (And to later add another auth handler for unregistered oauth 3 legged support) This way containers can pick and choose what they want.
4. I think it would be helpful for the sample container to actually issue 3 legged oauth tokens and store them in the jsondb. That way shindig could right off the bat go through an entirely real flow for oauth.
I'm going to try and build off of your patch for some of this and will post some new code to this issue soon.
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SHINDIG-897) Add 3-legged OAuth
validation support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671055#action_12671055 ]
chaowang edited comment on SHINDIG-897 at 2/6/09 3:29 AM:
------------------------------------------------------------
This new patch is targeting the support for for 3-legged OAuth validation. It includes:
1. Remove the "hasUserInstalledApp()" logic from OAuthConsumerRequestAuthenticationHandler - this ACL function should be delegated to the implementation of underlying 3 OpenSocial services.
2. Modify OAuthLookupService to expose only 1 API "getSecurityToken" that verifies the coming OAuth request and generates the security token if it's valid. The real validation work is delegated to a new OAuthDataStore interface, which is injected when SampleContainerOAuthLookupService initialized. This delegation model is consisted with PHP Shindig's.
3. Define OAuthDataStore as API (and its implementation SampleOAuthDataStore) to handle all OAuth consumer/accessor/token issues. This API should be easily fitting-in as an OAuth provider's facility.
2-legged OAuth validation has been tested against OpenSocial-Client Java Lib (http://opensocial-java-client.googlecode.com).
3-legged OAuth one has been tested against a reference implementation (http://term.ie/oauth/example/client.php).
was (Author: chaowang):
Supports validation for 3-legged OAuth.
This patch includes:
1. Remove the "hasUserInstalledApp()" logic from OAuthConsumerRequestAuthenticationHandler - this ACL function is delegated to the implementation of underlying 3 OpenSocial services.
2. Modify OAuthLookupService to expose only 1 API "getSecurityToken" that verifies the coming OAuth request and generates the security token if it's valid. The real validation work is delegated to a new OAuthDataStore interface, which is injected when SampleContainerOAuthLookupService initialized. This delegation model is consisted with PHP Shindig's.
3. Define OAuthDataStore as API (and its implementation SampleOAuthDataStore) to handle all OAuth consumer/accessor/token issues. This API should be easily fitting-in as an OAuth provider's facility.
2-legged OAuth validation has been tested against OpenSocial-Client Java Lib (http://opensocial-java-client.googlecode.com).
3-legged OAuth one has been tested against a reference implementation (http://term.ie/oauth/example/client.php).
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: add-3-legged-oauth.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SHINDIG-897) Add 3-legged OAuth
validation support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674609#action_12674609 ]
chaowang edited comment on SHINDIG-897 at 2/18/09 5:22 AM:
-------------------------------------------------------------
Hi Paul,
Just went through the code -- actually through "svn diff -r 744758 > ../r744758.patch", there're pretty many check-ins. =)
The code looks great. :)
Some thoughts:
* Consider changing the name of 2-legged OAuth handler and 3-legged one --- maybe we could call them OAuthThreeLeggedAuthenticationHandler etc straightforwardly.
* It seems like we could add some "write-back" logic to OAuthDataStore since:
a) Some OAuth extension needs to modify the OAuthAccessor and store it, and it might be not so flexible to write specific functions for each extensions.
b) New OAuthConsumer may need to be added into OAuthDataStore.
* Although I'm still thinking that OAuthEntry exposed too many low level details, like accessor layout, token, etc to the upper classes like OAuth###Handlers, it's also okay to me that take OAuthEntry as a "serialized" OAuthAccessor....
* For item 2, 3, 4 you mentioned, it seems like to be an okay solution to have a OAuthUtil class which hide all implementation details of OAuthAccessor<->OAuthEntry but only gives the "logical" functionality like "isAuthorized", "isExpired", "getAuthorizorID" etc etc.
just my 2 cents. :)
Cheers,
Jacky
was (Author: chaowang):
Hi Paul,
Just went through the code -- actually through "svn diff -r 744758 > ../r744758.patch", there're pretty many check-ins. =)
The code looks great. :)
Some thoughts:
* Consider changing the name of 2-legged OAuth handler and 3-legged one --- maybe we could call them OAuthThreeLeggedAuthenticationHandler etc straightforwardly.
* It seems like we could add some "write-back" logic to OAuthDataStore since:
a) Some OAuth extension needs to modify the OAuthAccessor and store it, and it might be not so flexible to write specific functions for each extensions.
b) New OAuthConsumer may need to be added into OAuthDataStore.
* Although I'm still thinking that OAuthEntry exposed too many low level details, like accessor layout, token, etc to the upper classes like OAuth###Handlers, it's also okay to me that take OAuthEntry as a "serialized" OAuthAccessor....
* For item 2, 3, 4 you mentioned, it seems like to be an okay solution to have a OAuthUtil class which hide all implementation details of OAuthAccessor<->OAuthEntry but only gives the "logical" functionality like "isAuthorized", "isExpired", "getAuthorizorID" etc etc.
just my 2 cents. :)
Cheers,
Jacky
However, I still have
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-897) Add 3-legged OAuth validation support
for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacky Wang updated SHINDIG-897:
-------------------------------
Comment: was deleted
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SHINDIG-897) Add 3-legged OAuth
validation support for RESTful api
Posted by "Jacky Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674534#action_12674534 ]
chaowang edited comment on SHINDIG-897 at 2/18/09 1:11 AM:
-------------------------------------------------------------
Thanks Paul! You move really fast! =)
Actually Cassie and me had some discussions on this OAuth implementation's architecture, here's the summary - Cassie, please correct me / add more details. :)
The whole things might include 3 layers:
[Layer 0: authentication handlers] 2-legged OAuth / 3-legged OAuth / unregistered OAuth (future)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Layer 1: interface, handles logical check-in, check-out, markAsAuthenticated, etc. functionality] as OAuthService
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Layer 2: storage specific, flatten standard OAuth* classes into DB rows "OAuthEntry"] as OAuthDataStore
The layer 0 is undoubtedly necessary. The reason why we separated 3 kinds of handlers is: although they could share some common code/flow, the container implementer might also want to have the flexibility to enable some of them (like 2-legged OAuth) and disable the remaining ones (like 3-legged one and unregistered one).
For the ACL (hasUserInstalledApp) issue, finally we came to the same idea that leaving it there in OAuthTwoLeggedAuthenticationHandler. It might be some comments followed to reminder the implementer taking care of the ACL check either there or in underlying opensocial handlers. On the other hand, adding the checking in OAuth handler is an additional benefit and won't harm those "underlying ACL" anyway.
It might also be helpful to abstract the layer 1 out as an interface. I suggest we still using OAuth* classes in the interface, thus the upper layer (handler) will not need to wrapper them -- the boundary of each layer might be much clear.
We're not quite sure whether the layer 2 should be abstracted out since it stands a bit closer to the implementation detail. But it could be very useful if we encapsulate the flatten code (OAuthConsumer -> consumerKey, consumerSecret; OAuthAccessor -> userId, consumerKey, token, tokenSecret, isAuthorized, type, issueTime, etc.) into an utility class thus container implementers could use them.
Finally we could end up with following classes:
== Authentication / Validation ==
[Level 0] OAuthTwoLeggedAuthenticationHandler, OAuthThreeLeggedAuthenticationHandler
(authentication classes, call OAuthService for data)
[Level 1] OAuthService, SampleOAuthService
(translates from OAuthEntry to the OAuthAccessor stuff that you need using the OAuthDataStore.)
[Level 2] OAuthDataStore, SampleOAuthDataStore
(classes to access OAuth storage)
OAuthEntry
(class modeling a row in DB)
== 3-legged OAuth granting ==
SampleOAuthServlet, SampleUnregisteredOAuthServlet
(classes look close to what Cassie has right now except as much oauth code as possible is pulled into OAuthUtil etc. to benefit containers with their own impls)
OAuthUtil
(a util class that does basic validation of messages, can verify request tokens etc etc)
I'm wrapping up the related code and will post some new code to this issue asap.
Thanks! =)
- Jacky
was (Author: chaowang):
Thanks Paul! You move really fast! =)
Actually Cassie and me had some discussions on this OAuth implementation's architecture, here's the summary - Cassie, please correct me / add more details. :)
The whole things might include 3 layers:
[Layer 0: authentication handlers] 2-legged OAuth / 3-legged OAuth / unregistered OAuth (future)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Layer 1: interface, handles logical check-in, check-out, markAsAuthenticated, etc. functionality] as OAuthService
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Layer 2: storage specific, flatten standard OAuth* classes into DB rows "OAuthEntry"] as OAuthDataStore
The layer 0 is undoubtedly necessary. The reason why we separated 3 kinds of handlers is: although they could share some common code/flow, the container implementer might also want to have the flexibility to enable some of them (like 2-legged OAuth) and disable the remaining ones (like 3-legged one and unregistered one).
For the ACL (hasUserInstalledApp) issue, finally we came to the same idea that leaving it there in OAuthTwoLeggedAuthenticationHandler. It might be some comments followed to reminder the implementer taking care of the ACL check either there or in underlying opensocial handlers. On the other hand, adding the checking in OAuth handler is an additional benefit and won't harm those "underlying ACL" anyway.
It might also be helpful to abstract the layer 1 out as an interface. I suggest we still using OAuth* classes in the interface, thus the upper layer (handler) will not need to wrapper them -- the boundary of each layer might be much clear.
We're not quite sure whether the layer 2 should be abstracted out since it stands a bit closer to the implementation detail. But it could be very useful if we encapsulate the flatten code (OAuthConsumer -> consumerKey, consumerSecret; OAuthAccessor -> userId, consumerKey, token, tokenSecret, isAuthorized, type, issueTime, etc.) into an utility class thus container implementers could use them.
Finally we could end up with following classes:
== Authentication / Validation ==
[Level 0] OAuthTwoLeggedAuthenticationHandler, OAuthThreeLeggedAuthenticationHandler
(authentication classes, call OAuthService for data)
[Level 1] OAuthService, SampleOAuthService
(translates from OAuthEntry to the OAuthAccessor stuff that you need using the OAuthDataStore.)
[Level 2] OAuthDataStore, SampleOAuthDataStore
(classes to access OAuth storage)
OAuthEntry
(class modeling a row in DB)
== 3-legged OAuth granting ==
SampleOAuthServlet, SampleUnregisteredOAuthServlet
(classes look close to what Cassie has right now except as much oauth code as possible is pulled into OAuthUtil etc. to benefit containers with their own impls)
OAuthUtil
(a util class that does basic validation of messages, can verify request tokens etc etc)
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: Java
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-897) Add 3-legged OAuth validation
support for RESTful api
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672129#action_12672129 ]
Cassie Doll commented on SHINDIG-897:
-------------------------------------
ps - the current patch works with the iphone os client library, although it always uses the canonical user as the viewer because the sample shindig doesn't have real auth...
> Add 3-legged OAuth validation support for RESTful api
> -----------------------------------------------------
>
> Key: SHINDIG-897
> URL: https://issues.apache.org/jira/browse/SHINDIG-897
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Jacky Wang
> Priority: Minor
> Attachments: alternativeOAuth.patch, supports-3-legged-oauth-validation.patch, supports-3-legged-oauth-validation.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> RESTful API now supports 2-legged OAuth, and we'd like to see it supports validation for requests issued by 3-legged OAuth client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.