Hey, thanks for the patch, Doug! Could you also sign up for an account at https://reviews.apache.org and create a review request for the patch? It's pretty straight forward, you just tell it which project and supply the patch with the repo that it was created against.
Then fill out the form as best as possible linking the bug name and filling in shindig for the group (so the dev list gets the review request). This should help people see the patch changes and understand them more easily. If you get stuck, just fire out an email here asking for help. From: daviesd <[email protected]> To: shindig <[email protected]>, Date: 12/07/2011 12:08 PM Subject: Re: OAUTH2 ClientAuthenticationHandler: No access to security token I¹m not 100% sure of how I submit a patch as a non-committer, but I¹ve created https://issues.apache.org/jira/browse/SHINDIG-1672 with a proposed patch for this issue. Essentially it passes the HttpRequest object along to the GrantRequestHandler so that it has access to things like the security token. This is necessary in our implementation because we need to pass along values from our trusted json within the security token to our request for the authorization code. In the meantime we are maintaining our own version of the BasicOAuth2Request class and injecting our own implementation of the CodeGrantTypeHandler. If/when this gets integrated into shindig trunk we¹ll switch over. Thanks, doug On 12/6/11 6:48 PM, "daviesd" <[email protected]> wrote: > I see where my misunderstanding was. I thought the > ClientAuthenticationHandler was called to set authentication values before the > authorization code request, based on this link (it¹s misleading). > > http://docs.opensocial.org/display/OSD/Client+Authentication > >> "Allows shindig developers to inject a new OAuth 2.0 Client Authentication >> handler into the flow to add authentication headers/etc. to all requests to >> the authorization and token enpoints for a provider." > > This does not appear to be the case. It looks like the GrantRequestHandler is > the appropriate place to add parameters you need before the authorization code > request happens. > > However BasicOAuth2Request does not pass along the original request (from the > makeRequest) nor the security token. It calls > > grantRequestHandlerUsed.getCompleteUrl(accessor); > > but the accessor doesn't have any of this info. I'll look into what it would > take to "patch" the code in order for the handler to have access to the > original request or security token. > > doug > > On 12/6/11 5:19 PM, "daviesd" <[email protected]> wrote: > >> Argh! Not so great. The security token seems to be null even though I see >> the st param on the makeRequest call. >> >> I don¹t see any way inside of my ClientAuthenticationHandler to get at the >> original request object or the security token. This presents a bit of a >> problem for me, since we need to pass along a bit of information from the >> token onto the authorization code request. >> >> Ideas? >> >> doug >> >> >> On 12/6/11 10:02 AM, "daviesd" <[email protected]> wrote: >> >>> I didn¹t notice that the request coming into addOAuth2Authentication wasn¹t >>> a HttpServletRequest but instead a >>> org.apache.shindig.gadgets.http.HttpRequest with a securityToken accessor. >>> Great!
