SEC-1745: Saved request lost across session timeout

[spring-projects-issues]

Drew Mazurek (Migrated from SEC-1745) said:

Using the SavedRequestAwareAuthenticationSuccessHandler configured as below, if the user's servlet session times out, after reauthentication Spring Security does not redirect the user to the URL he was trying to access. It instead sends him to the defaultTargetUrl.

<form-login login-page="/login" authentication-success-handler-ref="savedRequestAwareAuthenticationHandler" 
    authentication-failure-url="/login?authFailed=true"/>

<beans:bean id="savedRequestAwareAuthenticationHandler" class="org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler">
    <beans:property name="defaultTargetUrl" value="/start" />
    <beans:property name="targetUrlParameter" value="target" />
</beans:bean>

[spring-projects-issues]

Luke Taylor said:

This isn't a bug. If the session times out then the saved request is lost with it, since the default implementation of RequestCache uses the session for storage. If you want different behaviour you would need to use a different request cache implementation.

[spring-projects-issues]

Drew Mazurek said:

In terms of user experience, it's absolutely a bug. Two scenarios:

1. A user accesses an application for the first time at path /x/y/z. He's not logged in, so he's redirected to the login screen. After authentication, he's redirected to /x/y/z.
2. A user had already logged in but let his session expire. He tries to access /x/y/z and gets redirected to the login screen. After authentication, he's redirected to /default.

There's no reason that in the second scenario the user shouldn't be redirected to the page he's trying to access.

[spring-projects-issues]

Luke Taylor said:

Well, I disagree. Most stateful webapps I'm familiar with do not allow you to carry on after a session has expired as if nothing has happened. If there is any state associated with the session, then it is lost and you have to start again at a standard location. If you want the original destination to be available indefinitely you would have to send it back to the client and submit it with the login request.

[spring-projects-issues]

Drew Mazurek said:

I'm not talking about carrying on a session after it has expired. Restoring the session is my problem. What I care about is the current request. I want the user to experience the same behavior (of being redirected to the URL they were trying to access) whether they're logging in for the first time or they're logging in again because their session timed out. Why should those two situations -- which appear identical to the user -- result in different behaviors?

A more jarring use case for this fix is clicking on emailed deep links. If the user never had a session -- they have no JSESSIONID cookie -- they're shown the login page and then redirected to the link they were trying to access. If they have an expired session -- they have an invalid JSESSIONID cookie from, say, having their browser open in the background -- they're shown the login page and then dropped to the landing page. So from the user's point of view, sometimes these email links work, and sometimes they don't.

[spring-projects-issues]

Luke Taylor said:

The SavedRequest is cached in the session when an unauthenticated user attempts to access a secured resource (whether because the session has timed out or otherwise shouldn't matter in practice. If they then sit at the login page and allow the session to timeout then the saved request will be lost along with the session. Otherwise they will be redirected to the originally requested page as normal (unless you have configured alternative behaviour for when an invalid session ID is requested).

Please clarify which scenario you are talking about - i.e. requesting a secured URL then allowing the session to timeout before logging in (which will lose the original request information), or logging in immediately after a timeout (which should work as normal, and does when I test it with our sample app).

[spring-projects-issues]

Drew Mazurek said:

So I did a little more debugging and I found that the issue was due to setting the invalid-session-url in security.xml:

The SessionManagementFilter redirects the user to that URL and then halts all other processing. If I remove that URL, the filter chain continues and the login page as defined by is displayed. This also allows the request to be saved in the new session, so after authentication, the SavedRequestAwareAuthenticationSuccessHandler redirects the user to the URL they were trying to access.

So I guess it's not a bug, but it should be documented that invalid-session-url is incompatible with the SavedRequestAwareAuthenticationSuccessHandler.

Thanks!

[spring-projects-issues]

Luke Taylor said:

You might want to check out SEC-1724 and the related issue.