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