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!