The response code on the first request is a 200 and I see an access token
created in the db. Then the next call is the one that returns the 500. I
tried the “nocache” but wasn’t successful. Let me try again.
What I ended up doing was this (just to test — not necessarily the solution).
I extended DefaultRequestPipeline and then bound to it with Guice.
@Singleton
public class PlatformDefaultRequestPipeline extends DefaultRequestPipeline {
@Inject
public PlatformDefaultRequestPipeline(HttpFetcher httpFetcher,
HttpCache httpCache,
Provider<OAuthRequest> oauthRequestProvider,
Provider<OAuth2Request> oauth2RequestProvider,
@RewriterRegistry(rewriteFlow =
ResponseRewriterList.RewriteFlow.REQUEST_PIPELINE)
ResponseRewriterRegistry
responseRewriterRegistry,
InvalidationService invalidationService,
@Nullable HttpResponseMetadataHelper
metadataHelper) {
super(httpFetcher, httpCache, oauthRequestProvider,
oauth2RequestProvider, responseRewriterRegistry,
invalidationService, metadataHelper);
}
protected HttpResponse fixFetchedResponse(HttpRequest request, HttpResponse
fetchedResponse,
@Nullable HttpResponse
invalidatedResponse, @Nullable HttpResponse staleResponse)
throws GadgetException {
// Don't touch OAUTH2 requests (for now!!!)
if (request.getAuthType() == AuthType.OAUTH2) {
return fetchedResponse;
}
return super.fixFetchedResponse(request, fetchedResponse,
invalidatedResponse, staleResponse);
}
}
It just bypasses the fixFetchedResponse for oauth2 calls. When I do this my
gadget behaves as desired. Maybe that helps shed some more light on it.
doug
On Aug 20, 2014, at 4:30 PM, Stanton Sievers
<ssiev...@apache.org<mailto:ssiev...@apache.org>> wrote:
Hey Doug,
What's the HTTP response code on the first request that returns the
oauthApprovalUrl? From what I can tell, if the cachedResponse has a status
code >=400, we won't use it as the staleResponse in the case of a 500 error
on the subsequent request.
Regarding not caching your service calls at all, you can use the "nocache"
in the render parameters but that will result in ALL calls bypassing the
cache and not just your particular service calls.
Regards,
-Stanton
On Wed, Aug 20, 2014 at 11:18 AM, Davies,Douglas
<davi...@oclc.org<mailto:davi...@oclc.org>> wrote:
Hi Guys,
It’s Doug Davies. Been a while since I’ve been active on the shindig mail
list. We are getting back into our shindig implementation. We have
upgraded our container to the latest release.
We are having an issue that I think I brought up in the past, but I can’t
find the thread in the archives.
Here’s the scenario…
We have an oauth2 gadget that makes a request to one of our internal
services. That service happens to return a 500 error for a bad parameter
that gets passed in (I know probably not the right response, but I don’t
have control over that). When it makes the first call to the service it
gets back an oauthApprovalUrl like it should. I then present the UI for
that link to initiate the oauth2 handshake. Once it’s done the gadget then
makes the request again, this time with an access token. However, since
the service returns a 500 it seems the DefaultRequestPipeline code uses the
“staleResponse” (the last successful response that had the oauthApprovalUrl
in it) and so I get into an infinite loop.
I tried setting
params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 0;
but that doesn’t seem to matter. Ideas on how to solve this? Even if a
500 error isn’t the right response to be returning, it still seems like I’d
want to detect that this happened rather than the response looking like the
oauth flow needs to be initiated again.
In fact, I don’t know that I want any of my service calls being cached.
Thanks,
Doug Davies
