ERROR dispatch can cause two sessions to be created

[tsachev]

Updated Description

After further feedback from @tsachev the issue is reproduced:

• Initially there is no session created on the server and no session cookies in the browser.
• The controller/servlet creates a new session and sets an attribute. then throw an exception
• The error is handled and the SessionRepositoryFilter is invoked on the ERROR dispatch

This happens because the wrapped request that is caching the current session is not there anymore. It is a new HttpServletRequest object that is no longer wrapped. Instead, we should save the HttpSessionWrapper currentSession in a HttpServletRequest attribute.

Original Description

If a request creates a new session and then forwards (requestDispatcher.forward()) to another servlet/view which tries to update the session - two session are created.

if SessionRepositoryFilter is registered for DisptcherType.FORWARD - two spring sessions are created.
if SessionRepositoryFilter is not registered for DisptcherType.FORWARD - one spring session is created and one tomcat session.

I can see that two Set-Cooke headers are sent to the browser.

HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Set-Cookie: SESSION=8aa5f36e-820c-43bf-ba68-3797fd70b20f; Path=/storefront/; Secure; HttpOnly
Set-Cookie: SESSION=acc2a3df-ab9a-4080-afa3-c740fee75f5b; Path=/storefront/; Secure; HttpOnly
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 0
Date: Thu, 25 Jun 2015 14:56:10 GMT
Connection: close

[rwinch]

@tsachev Thanks for the report. I have modified the httpsession sample in a branch (rwinch/spring-session/tree/gh-229) to try to reproduce the issue and am unable to do so. The steps I attempted:

• The SessionRepositoryFilter is configured for REQUEST, ERROR, and ASYNC (it is not configured for FORWARD as this should generally not be necessary)
• Ensure Redis is running locally on the default port
• Start the application using ./gradlew :samples:httpsession:tomcatRun
• Submit the form with a value for the attribute name and attribute value
• The request sends a post to "/forward" which is handled by the ForwardServlet by:
  • Setting a session attribute named forward
  • forwarding to the SessionServlet which updates the attribute provided in the form

When looking at my cookies, I only see a single SESSION cookie. When looking in Redis I only see a single session. Both the attribute set before the forward and after the forward are displayed.

I'm wondering if the issue is related to the fact that your response is an ERROR? You may need to ensure the SessionRepositoryFilter is mapped to ERROR dispatch types as well.

Can you try and provide more details on how to reproduce this issue? Perhaps a sample?

Thanks!
Rob

[rwinch]

@tsachev PS Perhaps you could also let me know which version of Spring Session you are using. If you are not using 1.0.1.RELEASE perhaps you can try updating and seeing if that fixes your issue.

[tsachev]

I will try to make up a simple project that reproduces the problem.

But generally I think the flow goes like this.

• Initially there is no session created on the server and no session cookies in the browser.
• The controller/servlet creates a new session and sets an attribute. then throw an exception (thus the error in the response above).
• A custom exception handler forwards request to an error page (a jsp without <%@ page session="false" %>)

[rwinch]

@tsachev Thanks for the reply. This was enough information for me to reproduce the problem. I will get a fix for this issue in 1.0.2.

[rwinch]

Thanks for the report! I have fixed this in master and it will be available in the 1.0.2 release.

While I did test this myself, I'd appreciate you trying out the latest SNAPSHOT and ensuring that it resolved your issue. You can obtain the spring-session-1.0.2.BUILD-SNAPSHOT.jar from our maven repository:

<repository>
    <id>spring-snapshot</id>
    <url>https://repo.spring.io/libs-snapshot</url>
</repository>

PS: Based on your report I found another bug which we will also be fixing. See #251 Thanks again!