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 _______________________________________________ struts-menu-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/struts-menu-user
