Bug 53584 - Forms authentication without cookies requires double submission in 6.0.33
Forms authentication without cookies requires double submission in 6.0.33
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
PC All
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
: 54340 (view as bug list)
Depends on:
  Show dependency tree
Reported: 2012-07-22 23:28 UTC by b.mason@adinstruments.com
Modified: 2013-01-04 22:16 UTC (History)
1 user (show)

Standalone test app which reproduces the issue (2.94 KB, application/octet-stream)
2012-07-22 23:28 UTC, b.mason@adinstruments.com

Note You need to log in before you can comment on or make changes to this bug.
Description b.mason@adinstruments.com 2012-07-22 23:28:24 UTC
Created attachment 29093 [details]
Standalone test app which reproduces the issue

We have an application which uses the forms authentication provided by Servlet specification and is configured store session IDs in the URL rather than using cookies. This configuration has been working as expected under Tomcat 6.0.32 and earlier.

On upgrading to Tomcat 6.0.33 or 6.0.35 this combination no longer works as expected. Specifically, when a user initially submits the login form they are immediately returned back to the form-login-page. Submitting the login form a second time allows them to log in. The only difference I have been able to spot between the first and second form submission is for the second submission the request attribute "javax.servlet.forward.request_uri" now has the jsessionid appended to the URL.

Attached is a standalone WAR which reliably reproduces the problem with 6.0.33 and 6.0.35. Steps to reproduce:

1) Unpack tomcat 6.0.33. I used windows version "apache-tomcat-6.0.33-windows-x86.zip".
2) Drop forms-auth-test.war into the webapps directory.
3) Disable cookies by editing conf/context.xml:
<Context cookies="false">

4) Add a user to authenticated with to conf/tomcat-users.xml:
  <role rolename="tomcat"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>

5) Launch tomcat, I used "bin/catalina.bat start".
6) Navigate to http://localhost:8080/forms-auth-test/index.jsp
7) Enter user:tomcat pass:tomcat (should be prefilled). Click login.
8) Observe that you are returned to the login page (with a session ID in the URL this time).
9) Enter the username and password again and click login.
10) Login should succeed this time.

Environment details:
- Windows 7 64-bit, Oracle JVM 1.6.0u32 & 1.7.0u4.
- Debian 5 32-bit, Oracle JVM 1.6.0u32.

Relevant tomcat-user mailing list thread: http://tomcat.markmail.org/thread/kywykrrjvwuavndp
Comment 1 Mark Thomas 2012-08-07 21:33:38 UTC
Thanks for an excellent bug report. The issue was a real pleasure to investigate - not just because the root cause was interesting but because I could focus on the interesting bits rather than having to waste time trying to build the test WAR using the current flavour of the month for scm and/or build tool and/or source layout. Simple WARs are *SO* much easier to work with.

The clear steps to re-create the issue were also extremely helpful. So again, thank-you.

The root cause is that as of 6.0.33 path parameters are included the value returned from HttpServletRequest.getRequestURI(). During the FORM auth, one of the checks post authentication is "Does the current URI equal the original URI?" The problem is that the current URI always contains the session ID as a path parameter whereas the first time through the authentication the original URI does not.

This issue also affects trunk and 7.0.x.

I have fixed this issue in trunk and 7.0.x for 7.0.30 onwards and proposed the fix for 6.0.x.
Comment 2 b.mason@adinstruments.com 2012-08-09 21:29:51 UTC
(In reply to comment #1)

Thanks Mark. Glad my steps made the bug easy to reproduce. I'm a software developer myself so tried to add everything I would want in a bug report.
Comment 3 Mark Thomas 2012-08-27 21:29:55 UTC
Fixed in 6.0.x and will be included in 6.0.36 onwards.
Comment 4 Mark Thomas 2013-01-04 22:16:29 UTC
*** Bug 54340 has been marked as a duplicate of this bug. ***