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