RE: session race / transfer issue
I had a very similar problem some months back. It turned out to be a proxy server in the network caching pages too aggressively. We have a welcome screen that says hello to the user by name, based on a value pulled from session. Many times, anyone who logged in would be greeted by the wrong name, and always the name of the first person that logged on that day. The proxy was returning a cached copy of the page rather than sending the request through to the app server (verified by logging a message any time the Action that logged the user on fired, which is where the session was set up... I noticed the Action wasn't getting executed, yet the user was getting in, which could only be explained by the proxy returning a cached copy). Solution was to configure IE to not use the proxy for the address of this application. Coukd something like this be the case here too? -Original Message- From: Jesse Alexander (KBSA 21)[EMAIL PROTECTED] Sent: 2/10/05 8:01:43 AM To: Struts Users Mailing Listuser@struts.apache.org Subject: RE: session race / transfer issue -Original Message- From: Brown, James [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 4:30 PM To: user@struts.apache.org Subject: session race / transfer issue We have encountered a problem in which it appears (from user's description, transaction records, web application logs, and web server access logs), that user sessions are being transferred from one user to another. --- snipped --- We have inspected our web application code (all jsp, javascript, and java) and to our knowledge we are handling session creation, invalidation and access properly. In addition, we are using the html taglib and/or explicit encodeURL calls to insure URL rewriting is being enforced. --- snipped --- -- James the last time we have encountered such a problem it turned out to be something homemade within the application. The had stored that kind of data in a Action-instance variable. hop you find that bugger. Good luck Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [Message truncated. Tap Edit-Mark for Download to get remaining portion.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session race / transfer issue
I had a very similar problem some months back. It turned out to be a proxy server in the network caching pages too aggressively. We have a welcome screen that says hello to the user by name, based on a value pulled from session. Many times, anyone who logged in would be greeted by the wrong name, and always the name of the first person that logged on that day. The proxy was returning a cached copy of the page rather than sending the request through to the app server (verified by logging a message any time the Action that logged the user on fired, which is where the session was set up... I noticed the Action wasn't getting executed, yet the user was getting in, which could only be explained by the proxy returning a cached copy). Solution was to configure IE to not use the proxy for the address of this application. Coukd something like this be the case here too? -Original Message- From: Jesse Alexander (KBSA 21)[EMAIL PROTECTED] Sent: 2/10/05 8:01:43 AM To: Struts Users Mailing Listuser@struts.apache.org Subject: RE: session race / transfer issue -Original Message- From: Brown, James [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 4:30 PM To: user@struts.apache.org Subject: session race / transfer issue We have encountered a problem in which it appears (from user's description, transaction records, web application logs, and web server access logs), that user sessions are being transferred from one user to another. --- snipped --- We have inspected our web application code (all jsp, javascript, and java) and to our knowledge we are handling session creation, invalidation and access properly. In addition, we are using the html taglib and/or explicit encodeURL calls to insure URL rewriting is being enforced. --- snipped --- -- James the last time we have encountered such a problem it turned out to be something homemade within the application. The had stored that kind of data in a Action-instance variable. hop you find that bugger. Good luck Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [Message truncated. Tap Edit-Mark for Download to get remaining portion.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
session race / transfer issue
We have encountered a problem in which it appears (from user's
description, transaction records, web application logs, and web server
access logs), that user sessions are being transferred from one user to
another.
For example, two authenticated users:
* user A with session id 1 from ip 1.2.3.4
* user Z with session id 9 from ip 6.7.8.9
At some point the sessions are crossed (or half crossed) and we see the
following:
* user A with session id 1 from ip 6.7.8.9
* user Z with session id 9 from ip 1.2.3.4
A few things:
1) this is a rare condition 1%.
2) it may not be a complete crossing, we have seen instances where user
A is doing transactions from two IP addresses interlaced
(pseudo-simultaneously) in the transaction details/logs.
As a stop block measure, we have implemented a custom RequestProcessor
to map sessions to IPs. In the event that the IP associated with an
session changes, we invalidate the session and force re-authentication.
This is a stop measure and is not the ultimately desired solution.
Now, a little about the application:
* struts 1.1 - using url encoding/rewriting instead of cookies
* struts-menu 2.2 - with a slight modification to DisplayMenuTag.java
(as per
http://sourceforge.net/mailarchive/forum.php?thread_id=4195199forum_id=
32784) to handle url encoding issues. Snippet of revisions below.
* one module built via Oracle's BC4J framework
* primary integration/dao layer is EJB-based.
WebServer environment:
* Netscape iPlanet 6.1 connected through tomcat-connector to tomcat
4.1.24
We have inspected our web application code (all jsp, javascript, and
java) and to our knowledge we are handling session creation,
invalidation and access properly. In addition, we are using the html
taglib and/or explicit encodeURL calls to insure URL rewriting is being
enforced.
We have trolled BugZilla, mailing lists and google to no avail.
We have also not been able to replicate the problem via load testing.
Any suggestions, recommendations would be greatly appreciated.
DisplayMenuTag.java:
protected void setPageLocation(MenuComponent menu)
throws MalformedURLException, JspException {
HttpServletRequest request =
(HttpServletRequest) pageContext.getRequest();
// if the location attribute is null,
// then set it with a context relative page
// attribute if it exists
//
--
//
// Force the menu location to be set each and every time.
// As recommended/noted in:
//
http://sourceforge.net/mailarchive/forum.php?thread_id=4195199forum_id=
32784
// There seems to be a bug which results in the same session id
being
// used. This hack has been applied to our current source copy,
but
// hopefully struts-menu baseline will be updated with a corrected
// version.
//
// NOTE: Above article mentions also applying same patch to
// net.sf.navigator.taglib.el.DisplayMenuTag but it is currently
not
// needed within PPRS Refresh.
//
//
--
//if (menu.getLocation() == null) {
if (menu.getPage() != null) {
// are we sure we'll get an HttpServletRequest?
-- James
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
Re: session race / transfer issue
From: Brown, James [EMAIL PROTECTED] We have encountered a problem in which it appears (from user's description, transaction records, web application logs, and web server access logs), that user sessions are being transferred from one user to another. * Netscape iPlanet 6.1 connected through tomcat-connector to tomcat 4.1.24 Have you checked the archives for tomcat-user? I think a couple of people have reported something similar. Unfortunately, as a rare, seemingly random occurrence it's going to be hard to track down. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session race / transfer issue
At 9:37 AM -0700 2/9/05, Wendy Smoak wrote: From: Brown, James [EMAIL PROTECTED] We have encountered a problem in which it appears (from user's description, transaction records, web application logs, and web server access logs), that user sessions are being transferred from one user to another. * Netscape iPlanet 6.1 connected through tomcat-connector to tomcat 4.1.24 Have you checked the archives for tomcat-user? I think a couple of people have reported something similar. Unfortunately, as a rare, seemingly random occurrence it's going to be hard to track down. Is there any chance that there's a caching proxy in the middle? I've hit that 3 or 4 times, especially when you deal with multiple users inside a corporate network. Some ISPs also install caching proxies without telling their customers as a way of economizing on bandwidth. A few years ago we ran into this with the ISP for our office network. Needless to say, as a web development shop we noticed where their other clients might not -- and we dropped them soon after we noticed. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
