You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Eero Nevalainen <en...@gmail.com> on 2007/10/23 23:52:15 UTC
Tomcat mixes sessions?
Hello everyone,
I've got a really serious issue with session handling in my web
application. Some of my users complain that after they login into the
app, they actually see someone else's data! Personally, I have never
managed to replicate this, and most of the users seem to be perfectly
happy. So this is rare, but really bad as this is a financial
application...
I have really run out of things to check as this happens on two
separate versions of the application, the newer, current one coded
from scratch and running on Tomcat 5.5, the older was on top of
5.0.27. The new one is also behind Apache through mod_jk, old one was
standalone.
The application itself is nothing fancy. The login controller hits the
database, puts a "user" key in session with some user-specific data,
and after that, a front filter checks for the existence of the key for
login-restricted URLs. After that, it's just a matter of getting the
username from the session-stored object for subsequent queries. There
is no mutable static data anywhere in RAM in the app, all concurrency
is handled by the database, and even the session value object contains
only the user's info row from the database... so (just for
completeness -- it's a Spring controller) essentially on login we do
LoginData data = (LoginData) command;
// This is a completely trivial one
Person p = service.login(data.getUsername(), data.getPassword());
if (p != null) {
req.getSession().setAttribute("user", p);
req.getSession().setAttribute("prev_session_time",
p.getLastlogin());
return new ModelAndView(new
RedirectView("/members/ajankohtaista.jsp", true));
}
else
return showForm(req,res,exp);
The only common feature of the error reports is that the offending
machines seem to be located on workplace networks or somesuch. Not a
single report from a home user yet. Could it be possible that there
are two users behind some common proxy that is screwing things up?
It's driving me crazy really that session handling is supposedly a
simple matter, but apparently it just magically can go horribly
wrong... if this was some blatant code bug, one would think it would
really jump at you in an obvious way, and there isn't even that much
code to screw up :-(
TIA for any ideas,
Eero Nevalainen (enevalainen@gmail.com)
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat mixes sessions?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eero,
Eero Nevalainen wrote:
> The application itself is nothing fancy. The login controller hits the
> database, puts a "user" key in session with some user-specific data,
> and after that, a front filter checks for the existence of the key for
> login-restricted URLs. After that, it's just a matter of getting the
> username from the session-stored object for subsequent queries.
I would recommend installing an HttpSessionAttributeListener with
something like this for the implementation:
public void attributeReplaced(HttpSessionBindingEvent se)
{
if("user".equals(se.getName()))
{
System.err.println("'user' object was replaced in"
+ " the session.");
System.err.println("Old value: "
+ se.getValue());
System.err.println("New value: "
+ se.getSession().getAttribute("user"));
new Throwable("User replaced!").printStackTrace();
}
}
This will log an error message and complete stack trace whenever a user
is replaced in the session, and you'll be able to see which user was
replaced with which new one. This should at least give you a place to start.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHH06p9CaO5/Lv0PARAv0+AJ9Ltq2mxL0qeQwi9a8gxgSGdJl8SgCeNfz2
3KpYQ93fHOT862NiFWa6aYQ=
=0RLC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat mixes sessions?
Posted by Oliver Schoett <os...@sdm.de>.
Eero Nevalainen wrote:
> After that, it's just a matter of getting the
> username from the session-stored object for subsequent queries.
How do you store the session ID in the client browser?
I have seen a similar problem with a login page that handed out Session
IDs in the URLs contained in the page. The page was sent out with
"Cache-control: no-cache", but no "Expires:" header. The
"Cache-control:" header was introduced in HTTP 1.1, whereas in HTTP 1.0,
the only way to control caching is the "Expires:" header. A HTTP 1.0
proxy cache thus had no usable caching directive and applied its default
caching policy. As a result, users behind such a proxy could obtain the
same session ID and see each other's data.
Moral: when using "Cache-control:", always use "Expires:" as well for
HTTP 1.0 caches.
Regards,
Oliver Schoett
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat mixes sessions?
Posted by Konstantin Kolinko <kn...@gmail.com>.
Just to be sure. I hope that others have more fruitful thoughts.
1) Do you invalidate the session when the users log out ?
2) I do not like the following fragment:
> req.getSession().setAttribute("user", p);
> req.getSession().setAttribute("prev_session_time", p.getLastlogin());
It might be better to write
HttpSession session = req.getSession();
synchronized(session) {
session.setAttribute("user", p);
session.setAttribute("prev_session_time", p.getLastlogin());
}
There can be several requests being processed concurrently that belong
to the same session.
May be you have similar synchronization issues somewhere in your application?
3) Beware of ThreadLocal variables. They may persist information
across subsequent requests, even across different web applications, if
not cleared properly.
4) Different users may have different habits / application usage
patterns. E.g. office and home users may be different, or even there
are some outstanding ones, thus it might be not a network problem. May
be you can read httpd transfer logs or Tomcat AccessLogValve logs for
those ones that are complaining?
E.g. resubmitting, or opening several windows of the same browser, or whatever.
2007/10/24, Eero Nevalainen <en...@gmail.com>:
> Hello everyone,
>
> I've got a really serious issue with session handling in my web
> application. Some of my users complain that after they login into the
> app, they actually see someone else's data! Personally, I have never
> managed to replicate this, and most of the users seem to be perfectly
> happy. So this is rare, but really bad as this is a financial
> application...
>
> I have really run out of things to check as this happens on two
> separate versions of the application, the newer, current one coded
> from scratch and running on Tomcat 5.5, the older was on top of
> 5.0.27. The new one is also behind Apache through mod_jk, old one was
> standalone.
>
> The application itself is nothing fancy. The login controller hits the
> database, puts a "user" key in session with some user-specific data,
> and after that, a front filter checks for the existence of the key for
> login-restricted URLs. After that, it's just a matter of getting the
> username from the session-stored object for subsequent queries. There
> is no mutable static data anywhere in RAM in the app, all concurrency
> is handled by the database, and even the session value object contains
> only the user's info row from the database... so (just for
> completeness -- it's a Spring controller) essentially on login we do
>
>
> LoginData data = (LoginData) command;
>
> // This is a completely trivial one
> Person p = service.login(data.getUsername(), data.getPassword());
>
> if (p != null) {
> req.getSession().setAttribute("user", p);
> req.getSession().setAttribute("prev_session_time",
> p.getLastlogin());
> return new ModelAndView(new
> RedirectView("/members/ajankohtaista.jsp", true));
> }
> else
> return showForm(req,res,exp);
>
>
>
> The only common feature of the error reports is that the offending
> machines seem to be located on workplace networks or somesuch. Not a
> single report from a home user yet. Could it be possible that there
> are two users behind some common proxy that is screwing things up?
> It's driving me crazy really that session handling is supposedly a
> simple matter, but apparently it just magically can go horribly
> wrong... if this was some blatant code bug, one would think it would
> really jump at you in an obvious way, and there isn't even that much
> code to screw up :-(
>
>
> TIA for any ideas,
>
> Eero Nevalainen (enevalainen@gmail.com)
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org