Question

Have such problem: when use spring security 3, try to ask resource (via GET) or commit form (via POST) while should log in. So I redirected to log in form and then spring recover my original request, but it always recovered as GET request (even if I try to make POST request). So I wonder how can I fix it? Or may be how can I allow spring security to store only GET request and skip POST?

I found such code in DefaultSavedRequest:

public boolean doesRequestMatch(HttpServletRequest request, PortResolver portResolver) {

    ...

    if (!"GET".equals(request.getMethod()) && "GET".equals(method)) {
        // A save GET should not match an incoming non-GET method
        return false;
    }

So as I understand, this method compare cache request and incoming request and it shows that requests are not equals only if incoming request is not GET and storing request is GET. So in my case Storing request is POST and incoming is GET, so it return that the are equals, so it work wrong. What can I do with it? Is it bug or there some sense in such specific compare?

UPDATE.
I rerun error and see that my primary description was not full. I try to describe it more detailed. I have GET url, that opens form and it commits on the same URL via AJAX as POST with popup message window. I perform GET URL, form opens. Than I logout, and try to commit form. Popup window output error. I log in and redirected to URL (that are the same for GET/POST request), but on screen see not form, but JSON response of my AJAX request and in Firebug I see that after log in performs POST request. When I delete cache filter after login I redirected to the same URL, but it works not as POST request, but as usual GET request and opens form.

Answer 1

As the manual says, saved-request handling is a “best effort” approach. It can’t be all things to all people. It will cache a request (no matter what the request method, GET, POST etc) while it performs a login, and then redirect to the cached URL after login.

The incoming request after the redirect will be a GET (you can’t redirect to a POST, for example), so it will do its best to match this against the cached request and decide whether the cached request should be used to replace it, thus carrying on as if the login had never happened.

The code you have posted refers to the case where the user tried to make a GET request and was then prompted to login. If a subsequent request to the same URL is not a GET, it is not the result of the post-login redirect, so the cached request should not be used to replace it.

You can customize the RequestCache using the request-cache namespace element, or replace it with a no-op implementation. If you don’t want to use cached requests, you can set the always-use-default-target property of your form-login configuration.