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: dev@tomcat.apache.org
          Reporter: k...@emweb.be
    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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to