On 24/09/12 17:52, Mark Thomas wrote:
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.
Thanks Mark, I interpret your comment to be applicable to "proper
browser" behaviour, which is the appropriate context for a discussion on
the users list.
Unlike a "proper browser", the tomcat junit test class does a quite lot
of screen-scraping and cheating of headers and urls (not very elegant,
but it makes no claims to generality). My additional code was able to
easily identify the initial jsessionid, but detecting and handling a
changed value turned out to be more convoluted.
I think this thread can be wrapped up now without (hopefully) causing
confusion to future readers.
Regards,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
