https://issues.apache.org/bugzilla/show_bug.cgi?id=54340
Bug ID: 54340
Summary: Form-based authentication + url rewriting does not
work
Product: Tomcat 7
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Catalina
Assignee: [email protected]
Reporter: [email protected]
Classification: Unclassified
Created attachment 29788
--> https://issues.apache.org/bugzilla/attachment.cgi?id=29788&action=edit
Test case that reproduces the bug
Form-based authentication in combination with URL rewriting does not work: when
the user successfully authenticates he is redirected to the application but,
the login page is shown again. When he reloads this page then he does get to
the actual application !
The correct behaviour (which can be observed in for example jetty) is that the
user correctly can access the actual application after logging in.
The following access log illustrates the odd behaviour:
127.0.0.1 - - [21/Dec/2012:17:10:30 +0100] "GET /test-form-auth/protected
HTTP/1.1" 200 450
127.0.0.1 - - [21/Dec/2012:17:10:35 +0100] "POST
/test-form-auth/j_security_check;jsessionid=DBE966BD9F3CA8A7F57B5677F1D831F4
HTTP/1.1" 302 -
127.0.0.1 - - [21/Dec/2012:17:10:35 +0100] "GET
/test-form-auth/protected;jsessionid=DBE966BD9F3CA8A7F57B5677F1D831F4 HTTP/1.1"
200 450
127.0.0.1 - koen [21/Dec/2012:17:10:38 +0100] "GET
/test-form-auth/protected;jsessionid=DBE966BD9F3CA8A7F57B5677F1D831F4 HTTP/1.1"
200 59
Notice the two last requests: they are identical, yet, the server returns the
first time the login.jsp page, and the second time the actual web application.
On top of this (and perhaps related to these problems), in the actual web
application a different session ID is actually printed.
The same application in jetty regenerates the session ID (after authentication)
and directly redirects to this new session, reporting the same session ID
within the application as is visible in the URL.
The project in attachment is a self-contained test case that reproduces the
problem, including an ant script to create the war file.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
