Hello,
So let me answer this query, as it's related to a piece of non-optimal
design in Mid Tier that only raises its head in some circumstances. JSS
worked with another customer (ie not Frank) to diagnose this issue in
early May, and reported the issue to the BMC Premier Support team.
The core problem is related to multiple JSESSIONID cookies being sent to
the browser when Mid Tier is hosted in Weblogic. This causes a Mid Tier
second login within one browser window to fail (whether SSO enabled or
not), because two different session cookies exist that causes Mid Tier
to report 'invalid session'.
The broken session cookies are exhibited by Weblogic when following
these steps:
1. The user navigates to the BMC Mid Tier application and whether by SSO
or logging in manually, gains access. By this point, two persistent
(alive for the lifetime of the browser window) JSESSION cookies (the
Java web application reference to a session) have been sent to the
browser, and one of them poisons the browser. They are summarised as:
(a) Cookie with a value set against the path /arsys, which is the
correct way to set the application cookie.
(b) Cookie with a value set against the path /, which is not correct
and the poison.
2. The user uses the application and clicks logout.
3. The logout process kills the session and provides a new JSESSION
cookie against /arsys, which is correct.
4. The user navigates back to the application in the same browser window
and the following JSESSION cookies are sent:
(a) Poison cookie with the value set from (1), ie against /.
(b) Cookie with the value set from (3), ie against /arsys.
5. The poison cookie breaks the application during the login process
because the login has happened against the cookie from (3) and Weblogic
later picks up the cookie from (1), which no longer refers to an active
session, and hence the process fails.
If the user closes all instances of the browser window, starts a new
browser and navigates to the application, the process starts from (1).
The root cause is that Mid Tier is manually setting a JSESSIONID cookie,
ie the JSESSIONID cookie name is hard coded into Mid Tier. This can be
evidenced by changing the Weblogic session cookie name to something else
and noticing the JSESSIONID is still being emitted by Mid Tier. It is
also evident by grepping the Mid Tier class files:
$ grep JSESSIONID ./com/remedy/arsys/session/Login.class
Binary file ./com/remedy/arsys/session/Login.class matches
$ strings ./com/remedy/arsys/session/Login.class|grep JSESSIONID
JSESSIONID=
No Java web application should be manually manipulating the session
cookie. The Java servlet specification passes the session into the
application, and it's up to the application server (ie Tomcat, Weblogic,
etc) to manage the session cookie.
The reason this fault came to light is because, by default, Weblogic
sets the session cookie on the path / not /arsys (or whatever context
path is set). By changing the name of the session cookie, Weblogic still
set the cookie on / but it had a different name so wasn't confused with
the JSESSIONID value set by Mid Tier.
So if you're using Weblogic and maybe Websphere, you need to set the
session cookie name to something other than JSESSIONID for Mid Tier 8.1+
to work correctly.
John
--
Web Consultant, JSS.
http://www.javasystemsolutions.com/jss/ssoplugin
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
