[
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.
