Spring Sec. 3.1 Custom RequestCache removeRequest() never gets called

[dnc253]

We have a stateless app, so that means no sessions. We still want the functionality of redirecting a user to the URL they were trying to access before they were forced to login. Since Spring Security's default mechanism for doing this uses a session, we wrote implemented our own RequestCache. It basically sets a cookie with the URL they were trying to get to and then reads that cookie when they login.

It's all working great except for one thing. Spring Security never calls the removeRequest() method after successful login. As a result, the cookie never gets deleted. So, if they just logout, and then log back in (there wasn't a protected URL they were trying to get to), it sees the cookie and then directs to there.

I was looking through the source code of SavedRequestAwareAuthenticationSuccessHandler and found where we redirects to the SavedRequest retrieved from the getRequest() method on the RequestCache.

// Use the DefaultSavedRequest URL
String targetUrl = savedRequest.getRedirectUrl();
logger.debug("Redirecting to DefaultSavedRequest Url: " + targetUrl);
getRedirectStrategy().sendRedirect(request, response, targetUrl);

It seems like after getting the targetUrl, it should call removeRequest(), since it got what it needed from the SavedRequest. With the default HttpSessionRequestCache, the SavedRequest will go away as soon as the session is invalidated, but there are cases like this when the SavedRequest should be removed as soon as it's able to redirect. I wouldn't think there would be a problem with calling HttpSessionRequestCache removeRequest() at this point. Am I missing something here?

Is there a good workaround for this?

[Rob Winch]

It seems like after getting the targetUrl, it should call removeRequest(), since it got what it needed from the SavedRequest. With the default HttpSessionRequestCache, the SavedRequest will go away as soon as the session is invalidated, but there are cases like this when the SavedRequest should be removed as soon as it's able to redirect. I wouldn't think there would be a problem with calling HttpSessionRequestCache removeRequest() at this point. Am I missing something here?

Is there a good workaround for this?

The SavedRequestAwareAuthenticationSuccessHandler does not remove the request because not all the information associated with the saved request (i.e. request headers) can be included into the redirect URL. The redirect URL is simply to trigger the RequestCacheAwareFilter to obtain the SavedRequest from RequestCache#getMatchingRequest(). This method is responsible for returning the matching request and remove the saved request. At that point the RequestCacheAwareFilter replaces the original HttpServletRequest with the SavedRequest which ensures that other properties of the request are also present (i.e. headers).

[marcovmx]

... RequestCache#getMatchingRequest(). This method is responsible for returning the matching request and remove the saved request.

That should be said in the api docs. No clue about that.

[Rob Winch]

That should be said in the api docs. No clue about that.

Can you clarify what you mean by it should be in the api docs? The javadoc states that it should be removed. I have included the javadoc below for your convenience.

Returns a wrapper around the saved request, if it matches the current request. The saved request should be removed from the cache.

[marcovmx]

You are totally right. I had a quick look to the method summary that says:

Returns a wrapper around the saved request, if it matches the current request.

Drilling down the details you can read the saved request should be removed. My mistake