https://bz.apache.org/bugzilla/show_bug.cgi?id=65755
--- Comment #2 from dimitrios.psymar...@atos.net ---
Hi,
We have already checked if there are any possible "leaked" references to the
request/response/session objects outside of their normal scope, but this
doesn't seem to be the case.
Just to give you a better understanding of our situation, we have a Servlet
Filter which performs an automatic login based on a Cookie (by default this
Cookie expires after 30 days). After each automatic login this expiration date
is refreshed again in order to make it last for 30 days more. You can see a
simple representation of this implementation in the following snippet using
pseudocode for a better understanding:
**************************************************************
public class AuthenticationCheckFilter implements Filter {
...
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
...
// If (user is not logged)
// Read authentication cookie from "request" object.
// Perform automatic login using the cookie.
// Refresh the cookies expiration date in order to be valid
for
// 30 days more using the "response" object.
// End If
...
}
...
}
***************************************************************
So if the user is not logged in (does not have a valid session at that point)
the authentication cookie (from the "request" object) is read and used in order
to perform an automatic login. After the successful completion of the
automatic login, the cookie's expiration date is refreshed (by using the
"response" object). The problem is that the response with the updated cookie
ends up to a different user session from the one that it was supposed to go.
So a different user will receive the SET-COOKIE header (with the updated
expiration date) that was intended for another user and he will be able to
eventually login to the other user's account.
In our understanding there is not something wrong with our logic here that
might end up mixing different user sessions since we don't keep any reference
on the request/response objects outside of the doFilter method. We just use the
request/response objects that are provided as parameters from the doFilter
method which are related to the current user session and not any other external
references on other sessions.
We are not sure if the previously mentioned errors are related to the mixing of
the different user sessions (or this could be a "silent" bug without traces)
but these are the only ones that are reported in the catalina logs.
Regarding you second question yes we are using Websockets and more specifically
we are using the atmosphere websocket framework (as it can be seen from the
second stack trace which seems to be related to WebSockets).
We have already upgraded our software to use the latest Tomcat version (8.5.73)
and so far the issue has not been reproduced yet (but keep in mind that this is
not easily reproduced). However since this is a really critical issue we
couldn't risk it by just waiting if the new version will fix this issue and
that's why we opened this ticket (we also couldn't find anything related in the
old reported/resolved issues).
In the past we were using version 8.0.49 (until it 8.0.X reached EOL) and we
later moved to version 8.5.43 but we never had such issues until the point we
upgraded to version 8.5.64. Also note that during these upgrades we didn't
perform any change to other stongly related (to this flow) libraries/frameworks
that could be "suspected" as problematic (websocket atmosphere framework,
Jersey) that's why we think that this is a Tomcat issue.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
