(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();
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
// 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?
//
// 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.
