Igor Vaynberg-2 wrote > > jsessionid is managed by the servlet container. we cant encrypt it > because its not part of the page path or query string, its in its own > weird ;jsessionid thing that containers mangle in there. maybe your > container has an option to encrypt it, or maybe you can write a plugin > for it that encrypts it... >
Yeah, there is no Wicket problem here. I caught the WebResponse in the debugger at the end of a request cycle, and there was no jsessionid in there. The container is somehow magically pre-pending it to every single url in the response markup. For most situations, I think the newish WebSession.replaceSession (post 1.4) takes care of the "session fixation" problem. There's also a Tomcat valve (post 5.5.29) that issues a new session id after authentication: <Valve className="org.apache.catalina.authenticator.FormAuthenticator" changeSessionIdOnAuthentication="true" /> But messing with the session id for me invokes chaos with the underlaying legacy auth layer I'm dealing with. Wicket is still awesome, though! L. Burlap -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-url-encoding-ClassCastException-using-SunJceCrypt-tp4090613p4094435.html Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
