Hi Christopher, I've deployed the test app on one of my test boxes (sorry, no DNS - only IP-Address):
http://178.238.228.136:8080/TestServlet Dump of TestServlet.java: import java.io.IOException; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; /** * Servlet implementation class TestServlet */ @WebServlet("/TestServlet") public class TestServlet extends HttpServlet { private static final long serialVersionUID = 1L; @Override protected void doGet(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException { HttpSession session = request.getSession(false); String originalSessionId = null; if (session != null) { originalSessionId = session.getId(); session.invalidate(); } session = request.getSession(true); String newSessionId = session.getId(); if (newSessionId.equals(originalSessionId)) { throw new IllegalStateException( "New session has the same ID as the old one: " + newSessionId); } PrintWriter writer = response.getWriter(); writer.print("<html><body>"); writer.print("<h1>Ok. Session IDs are different</h1>"); writer.printf("Original Session ID: %s<br/>", originalSessionId); writer.printf("New Session ID: %s<br/>", newSessionId); writer.print("</html></body>"); } } And the minimal context.xml in META-INF causing the error: <?xml version="1.0" encoding="UTF-8"?> <Context sessionCookiePath="/" /> There is nothing more in the WAR but these two files. And yes, it doesn't matter much, which context you choose. I've deployed the same WAR on the same server again as test.war: http://178.238.228.136:8080/test/TestServlet Java Class and context.xml are the same. If you're playing around with both at the same time please be aware that they effectively share the same sessions as both WARs use a "/" cookie path. I briefly configured another cookie path for the second test.war ("/test/") and the error *did not* occur. Please tell me when you're done with testing so that I can take the server offline again. Stefan On 03.10.2013, at 14:40, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Stefan, > > On 10/3/13 5:40 AM, Stefan Haberl wrote: >> I've created a minimal test case to isolate the problem. The >> TestServlet is not doing much but invalidating sessions, generating >> new ones and checking if the new one gets a different ID than the >> old one (see attached WAR). IMHO I think this could be a Tomcat >> bug? >> >> Steps to reproduce the problem: >> >> 1. Install fresh Tomcat 7.0.42 2. Remove default webapps/ROOT > > Is it important that the webapp run as ROOT? Or can it have another > context path? > >> 3. Deploy the attached WAR including the TestCase as >> webapps/ROOT.war > > This list strips attachments. Perhaps you could create a bug in > Bugzilla and attach it there? I'm not yet convinced there is a Tomcat > bug, so perhaps BZ isn't the right place quite yet. Your other option > would be to host the example webapp somewhere and post a link. > >> 4. Fire up Tomcat 5. Browse to localhost:8080/TestServlet 6. Reload >> the page ==> ERROR: No new session ID will be created >> >> As soon as you comment out the sessionCookiePath="/" line at the >> context descriptor inside the WAR (/META-INF/context.xml) you can >> reload the page (Step 6 above) as often as you like and new session >> IDs will be generated as they IMHO should be to prevent session >> fixation attacks. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJSTWXIAAoJEBzwKT+lPKRYyskP/jhbmQ6LyT7WPGZh9iCgfDt4 > +o0wuTicFKteLuWRDQAVWVoJjZ/PbcjJrUCEnbTyKVBHZbnscGX/c02bxJqkShA0 > DE99rVBRiZw78LSXDnf9ZzG7s2xyEvFz5H+FMh2CvCkXL+Ihgi1OGhsq2Q3N1eyu > dGRCMCXzwNQ8V+D9mbXJP5ZxP633K+jFWbmppXm5Wo9dWMHVz343uMcf3utevbL7 > 20bhbqQETVRrBxnK8YsJwOi+28+nOzoj1RImyVYCANYm/xOkbUDlCTs1GRABfboC > 6rSP89ttjB4KjOepmlvQgFcBsfK3cO25LaOINbI52DkqgOpYsL+CGn8ft37a6Cxi > H3WIViAqEslhDeh+fejDtAiYjiWUHErn7IaBzbuuW0ZFjecGaB7XbDTg45Az/UE1 > rbQeDVS9R9/GPr5qqMBXKw8a2Pd1zk0T5FWTL8Yha9BP7OFAqdK/XWFBh+Wuhf7e > ZX7nqQZmExU+qqJMatNYBXfTf9C2PqkcxearQ0CqpxMd4iehtj2YZX4iL2MVTA+r > gXAPWzP5mp5ni4XMBiCtF9pIKx0CIBtOukEVcSrGrWzmAHLGzQDuxXiaIU84A4/q > IhdGLfIUzH7ZypEbHTO7nYe3WfyFAEUSKU+lTXqad6dugRmbwDeHSEgFPBpDW+Wt > K1GI91YXOFy9jQF/eSY+ > =J9dK > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- Stefan Haberl http://christa-und-stefan.net --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
