Re: session race / transfer issue

There's no reason to cross-post to the different lists.  I'm the main  
supporter of this project and I'm subscribed to both lists.  It sounds  
like this problem *might* be related to struts-menu, but you're not  
sure.  Is that the case?

Is there any way to consistently reproduce this error?  This is what's  
needed to isolate the problem and try to fix it.

Thanks,

Matt

On Feb 9, 2005, at 8:35 AM, Brown, James wrote:

> (Cross-posted to struts-menu-user, struts-menu-devel, and struts-user  
> mailing lists)
>  
> 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=4195199&forum_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=4195199&forum_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.
>   
>  
>
>
>
> -- 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.
>   



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click