>No, you'd have to write your own authentication mechanism. Tomcat is >required to store the request that triggered authentication for re-play >after a successful authentication. If not the request, where else should >it be stored?
Christopher, thanks for the reply. This is inline with my analysis. Actually, I am trying to address 'Session Fixation' issue in my web application. I saw your reply on thread http://www.nabble.com/How-to-avoid-session-fixation--td15311806.html. In one of the reply you gave following suggestion to address the issue: - a custom valve contains the whole implementation - requests to the servlet/URI "j_security_check" are intercepted - for intercepted requests the current session is destroyed and a new one is created: -- snip -- ... request.getSession().invalidate(); request.getSession(true); ... -- snap -- - to have a proper redirect to the originally requested page the original request has to be copied from the old session to the new one. I filter out any references to the old session id, although I'm not sure whether this is really necessary. I think, this would solve my problem. The only blocker for me is step: "requests to the servlet/URI "j_security_check" are intercepted". I did not get good info on google which would teach me how I can do this. Pointers on this would be of great help. Thanks, Umesh P.S: BTW, is Tomcat planning to resolve this vulnerability in near future? -- View this message in context: http://www.nabble.com/Form-Based-Authentication-creates-user-session-before-it-is-authenticated--tp23455945p23515249.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
