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" <davi...@oclc.org> 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" <davi...@oclc.org> 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!

Reply via email to