[jetty-dev] [jira] (JETTY-1529) Superfluous re-authenticate changes session ID uncoditionally on second request

Koen Deforche
commented on JETTY-1529

Superfluous re-authenticate changes session ID uncoditionally on second request

Hey Jan,

Thanks for the workaround, that works indeed.

Your comment made me realize that this is probably because we are deploying with cookies for session tracking disabled. In this way, the first request might create a session but the redirect to the login page does not retain this ?

I've attached a test case. To reproduce, open /protected/hello.jsp, login using guest/guest. Occasionally (press reload if necessary) you will get a broken image and an error like this:

2012-07-05 09:53:15.039:WARN::/protected/wt_powered.jpg;jsessionid=1q61mq23ranll1ii7ivsynow6j

java.lang.IllegalStateException

at org.eclipse.jetty.server.session.AbstractSessionManager$Session.getAttributeNames(AbstractSessionManager.java:888)

at org.eclipse.jetty.security.authentication.LoginAuthenticator.renewSessionOnAuthentication(LoginAuthenticator.java:71)

at org.eclipse.jetty.security.authentication.BasicAuthenticator.validateRequest(BasicAuthenticator.java:80)

at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:439)

at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)

at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:937)

at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)

at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)

at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:871)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)

at org.eclipse.jetty.server.Server.handle(Server.java:346)

at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)

at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1048)

at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:601)

at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)

at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:535)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)

at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)

at java.lang.Thread.run(Thread.java:662)

The priority of this problem is probably even less than minor now, since we realize it is triggered by the URL-encoding of the session ID (I suspect?), and because with servlet-based authentication, the URL-encoding for the session ID becomes undesired since it appears in the URL. Until now the application was a single-page web app which did not suffer from this.

Regards,

koen

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators .

For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email