This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
We're having a bizarre problem that crops up on rare occasions with our beta web application (we have a small, confined universe of users at the moment). Once in awhile, a user will report that they attempted to log into our site, and will successfully do so, but instead of being logged in as themselves are actually logged in as someone else!
Obviously there are a number of things going on under the covers and no one could possibly solve the problem on this site. But... has anyone ever had this happen to them? I figure it probably has to do with either the JSESSIONID value from either a cookie or URL rewrite being accidentally hijacked by the user; or, it has to do with the login action returning data from the wrong user.
Regarding the latter, we are using a Stateless Session Bean which is given the username/password, checks in the database for a match, throws one of various exceptions if it find no match, or otherwise sends a User object back with the now-logged-in user's data. I checked the log from the most recent "hijacking" incident, and there were definitely multiple users logging in at about the time it occurred. Are there situations where some kind of race condition could occur, where a Session Bean that is halfway through the authentication process suddenly becomes used to log in a second user?
Thanks in advance...
Dave Taubler<br />Specializing in <a href="http://taubler.com/articles/" target="_blank" rel="nofollow">Java and Web Development</a>
Something like what you described might happen if you�d be using a servlet that has some kind of state which is not properly synchronized. If such a servlet for example, would maintain a list of connected users and the list is not properly synchronized then you�ll definitely face a similar situation. Using SLSB you might not face the same problem unless your SLSB maintains some state. For example if your SLSB would define two attributes like username and password, which are changed inside any of the business methods, then you might have a serious problem. Also isn�t possible the hijacking to happen somewhere else like the servlet example above? Another way for this to happen is when the same users logs twice, from the same computer using different accounts. If s/he opens the browser and logs in as user A and opens another browser and logs as user B, now if s/he goes back to the fist screen and do some work, will actually change A�s data as user B (since the session cookie was overridden). As silly as it sounds, but this actually happens to many sites that are not properly secured. Regards.
I think, therefore I exist -- Rene Descartes
Joined: May 15, 2001
Thanks for the tips. There definitely are no member variables anywhere in the stateless session bean--in fact, I was originally using a stateful session bean for login, and in that case did have member variables, but have since then changed to a stateless bean and removed all member vars.
We fortunately have one of the affected users who is willing to work with us to help figure out the root of the problem. He sent his Internet Explorer cookie file to us. Like many sites, we employ the "Remember Me" option, whereby we store a username cookie and a password cookie for auto-relogin (I need to change things so that we store a hashed password, not a plaintext one, but that's another story! ) Anyhow, this IE cookie file clearly shows the wrong user's (e.g the "hijacked" user's) username and password, rather than the actual user's username/pwd.
So the thing I am looking at now is where the cookies are written. I have a "DataCache" object which I store in the user's session. This DataCache contains everything we know about the user, including the current request parameters, username/id/displayname/preferences/etc, as well as references to the current HttpServletRequest and HttpServletResponse objects. What I am thinking now is that maybe our code is somehow retrieving another user's HttpServletResponse object and writing the cookies there.
Joined: Feb 17, 2005
What I am thinking now is that maybe our code is somehow retrieving another user's HttpServletResponse object and writing the cookies there.