Tomcat6 bug report

[Orlando José Luque Moraira <do...@gmail.com>]

Hi, first time here.

Found in tomcat6, not sure if it have been solved / changed in a newer
version.

Resumee: in a URLed jSessionId controlled session, if you do, from the
client, one or more html requests to get files but without jSessionId in
the URL, tomcat create a new "general site" cookie with a new jSessionId
and this new cookie is stored in the client. After a jSessionId is set in
that "general site" cookie, the jSessionId of the cookie is used instead of
the URLed jSessionId value, which is completely ignored from now, breaking
the URLed jSessionId functionality completely.

Example of requests in a row:
furball.com    <-- server: set-cookie: jSessionId = 1234
furball.com;jsessionid=1234 --> we see the cookie in the client
furball.com/other  <-- server: set-cookie: jSessionId = 5678
furball.com;jsessionid=1234 --> it ignores the 1234 and starts using the
cookie jSessionId, so the jSessionId dissapear from the URLs shown in the
page... really it is a new session :-(


Any subsequent html request is flawed in the same way until you manage to
clean that cookie.


Seems like those new cokies are stored... in like a new local
not-session-related-cookie. As said, any subsequent html request will have
its jSessionId ignored and tomcat will use the one stored in that
"not-session-related-cookie", so you lose your original session and are in
danger of corruption between tabs with different sessions.

In a embedded webbrowser, this breaks all sessions working until you
restart the embedding application.

In webbrowser applications (as firefox) suffer the same way and as far as I
saw, deleting al cookies did not solve the issue. Weird. (I have the cache
madness so much... :-S).



Please, have this been resolved in newer versions? If possible, in which
one?

Thanks!

Regards,
       Orlando

Re: Tomcat6 bug report

[Mark Thomas <ma...@apache.org>]

On 12/06/17 14:15, Orlando José Luque Moraira wrote:
> Hi, first time here.

This question belongs on the users list, not on the dev list.

Mark


> 
> Found in tomcat6, not sure if it have been solved / changed in a newer
> version.
> 
> Resumee: in a URLed jSessionId controlled session, if you do, from the
> client, one or more html requests to get files but without jSessionId in
> the URL, tomcat create a new "general site" cookie with a new jSessionId
> and this new cookie is stored in the client. After a jSessionId is set in
> that "general site" cookie, the jSessionId of the cookie is used instead of
> the URLed jSessionId value, which is completely ignored from now, breaking
> the URLed jSessionId functionality completely.
> 
> Example of requests in a row:
> furball.com    <-- server: set-cookie: jSessionId = 1234
> furball.com;jsessionid=1234 --> we see the cookie in the client
> furball.com/other  <-- server: set-cookie: jSessionId = 5678
> furball.com;jsessionid=1234 --> it ignores the 1234 and starts using the
> cookie jSessionId, so the jSessionId dissapear from the URLs shown in the
> page... really it is a new session :-(
> 
> 
> Any subsequent html request is flawed in the same way until you manage to
> clean that cookie.
> 
> 
> Seems like those new cokies are stored... in like a new local
> not-session-related-cookie. As said, any subsequent html request will have
> its jSessionId ignored and tomcat will use the one stored in that
> "not-session-related-cookie", so you lose your original session and are in
> danger of corruption between tabs with different sessions.
> 
> In a embedded webbrowser, this breaks all sessions working until you
> restart the embedding application.
> 
> In webbrowser applications (as firefox) suffer the same way and as far as I
> saw, deleting al cookies did not solve the issue. Weird. (I have the cache
> madness so much... :-S).
> 
> 
> 
> Please, have this been resolved in newer versions? If possible, in which
> one?
> 
> Thanks!
> 
> Regards,
>        Orlando
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org