The same issue exists for WebSphere as well. Axton Grams
On Tue, Jun 10, 2014 at 3:21 PM, John Baker <[email protected]> wrote: > 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
