On 24/09/2012 11:41, Brian Burch wrote: > I draw the following conclusions: > > 1. A client that can accept a Set-Cookie for JSESSIONID will be able to > maintain a persistent session (is that incorrectly overloading a > reserved word?), no matter whether the session ID is changed once, many > times, or not at all.
Correct. > 2. A client that cannot accept cookies will only be able to maintain a > persistent session IF the server sends the correct (current) jsessionid > as a path parameter appended to ALL urls within its response. That is > achievable with servlets, jsps, jstl (all of which which can ask for an > encoded url to be inserted into the dynamic web page). It cannot work > with static html. Correct - Unless one starts parsing the static HTML e.g. via a filter and adding the path parameter. Messy but doable. There might even be a filter out there that does this. For example, httpd has a module that does this > 3. Therefore, any webapp that MIGHT need to authenticate a client that > does not accept cookies MUST generate EVERY protected resource url > dynamically (to include the session ID). Correct - part from the option above. > 4. Any webapp that cannot satify case 3 MUST turn off > changeSessionIdOnAuthentication for its Context and degrade the session > fixation protection for ALL of its clients. No sure I agree with this. If the URLs aren't being encoded then the session is going to break regardless of whether or not the session ID changes. > Do you agree, or have I misunderstood something in my analysis? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
