Concurrent sessions on multiple web apps?

[Justin Chu]

If I am on webapp "/app1Web", and accesses "/app2Web" on the same server, that invalidates my session on "/app1Web".

That is happening on WebLogic. I wonder if this is normal, or this is an issue with my code.

The way I access "/app2Web" is actually a POST from "/app1Web".
[ March 08, 2007: Message edited by: Chu Tan ]

[D Rog]

It should be issue with your code. Server won't invalidate your session unless timeout reached.

[Justin Chu]

It turns out that weblogic JSESSIONID cookie uses the '/' path by default, and the 2nd application will override the cookie. All I need to do is to configure the cookie to the context root path for each application.

[Jeanne Boyarsky]

First of all, yes - I'm well aware that I'm bumping a two year old thread. It helped me a lot. We were struggling with this problem for a few weeks and this thread pointed us right at the solution.

I didn't find this thread earlier despite much searching because I wasn't using the right search terms. And because the web is cluttered with questions about sessions being invalidated prematurely due to timeouts and trying to access the same session across multiple applications. Since this thread helped me so much, I want to give it some good karma.

------------------------------------------------------------------------------------------------------------------
Here's the question I would have asked that this thread answers. Along with some extra information that I learned was important upon the long road to a solution.

I want to interact between multiple applications on the same domain. They are on different logical application servers under the same install/cell. The user will click on links within one application which will take it to the other and back. I expect the original HttpSession for each application will still be there with all the current information. I'm not trying to share the same session across applications, just to let them both exist simultaneously. The problem is as soon as I go into the second application, the first application's session is invalidated.

At first I thought the single sign on manager (like Siteminder or WebSeal) was messing things up. Turns out this wasn't the case. The problem occurs with just the application server (like WebLogic or WebSphere.)

Looking at the headers using a Firefox plugin like LiveHeaders helps show the actual problem - the one Justin identified in this thread. When the root "/" is set as the cookie path, the reference to the session is lost. When you hit the second application, it sticks the jsessionid for that application in the cookie - which overwrites the pointer to the session of the first application. When you go back to the first application, it uses the second application's jsessionid - which of course doesn't match. So it creates a new session overwriting the link to the session for the first application. And the problem cycle continues.

Changing the "/" to "/path1" and "path2" (where path1 and path2 represent the URLs used by the two apps) allowed both sessions to have pointers at the same time. Problem begone.

So thank you Justin for sharing the solution. We always say posting the solution helps others who later have the problem. And this time it was me!



If I am on webapp "/app1Web", and accesses "/app2Web" on the same server, that invalidates my session on "/app1Web".

That is happening on WebLogic. I wonder if this is normal, or this is an issue with my code.

The way I access "/app2Web" is actually a POST from "/app1Web".

[Skanda Raman]

Thank you Jeanne. You provided the detailed explanation.

I am now struggling with this problem of session invalidation. As you mentioned, please let me know if you are suggesting to set the path in JSESSIONID. I am trying to do as below. Please advise if this is the right approach.

1. Get the list of cookies from request from below code.

Cookie[] cookie = request.getCookies();

2. Loop the cookie array and find JSESSIONID and set path to my application context path and then add to response header.

OR can i create a new cookie from my application and add the path.

Please advise.

[Jeanne Boyarsky]

You shouldn't be updating that cookie directly. It is getting the path from a server configuration.

[David Balažic]

Jeanne Boyarsky wrote:You shouldn't be updating that cookie directly. It is getting the path from a server configuration.

FYI, that is done in WEB-INF/weblogic.xml :
<session-descriptor> <cookie-path>/myApp</cookie-path> </session-descriptor>

I run into this recently with WebLogic 10.3.5 deploying two apps.
But instead of one app invalidating the session also for the other app, I experienced that invalidating the session in one app does not do (almost) anything, if there is an active session on the other.

Details:
- user only opens app1, he gets a JSESSIONID cookie
- user clicks a link that calls session.invalidate()
- when user loads a page from app1 that uses a session, he gets a new value in the JSESSIONID cookie

But in this case:
- user opens app1, he gets a JSESSIONID cookie
- user opens app2, the JSESSIONID cookie remains the same
- user clicks a link in app1 that calls session.invalidate()
in this case the OP reported that both sessions are lost, but in my case not. The JSESSIONID value remained the same and app2 continued to work with the old session (this is good). But app1 still also used the same JSESSIONID value (the session itself was destroyed and later replaced with a new one).

Maybe this was a fix added in WebLogic 10.3.5 (or a bit earlier)?

Now the problem and the reason I am writing: The described fact that the JSESSIONID value remains the same even if the app invalidates the session leaves the doors open for a "session fixation" attack (see description links below).

JBoss (at least 7.1.1) and tomcat (8.0.x) behave differently. They send a different cookie for each app, having path=/app1 and path=/app2
Is WebLogic deviating from the specs? The behavior is sure surprising.

Links:
Session fixation description at wikipedia
Session fixation description at OWASP

[David Balažic]

Additional details:

after calling session.invalidate() the request.getSession().getId() returns a different value, but the cookie value stays the same.

Example (the values are shortened by few characters for clarity):

getId() before:
lv2sZprhrVD7Tmc3hx!-14701!421089720

calling invalidate() , then getSession(true)

getId() after:
lv2sZprhrVD7Tmc3hx!-14701!421253573


cookie value before and after:

lv2sZprhrVD7Tmc3hx!-14701

So:
- the session id changes after invalidate();getSession(true); but only in the last few characters
- the cookie value lacks the last item and remains the same

[David Balažic]

If anyone is reading...

I did another test on another system (same software versions) and now the cookie contains the full value: wG...8vB!-1537443802!168028721

After invalidating the session, the cookie value changes (the two numbers at the end change value, the alphanumeric code in the front stays the same).

I guess only a WL wizard clould explain it...

[Tim Holloway]

David Balažic wrote:

I guess only a WL wizard clould explain it...

Wrong. I can explain it!

You should never mess around with the jsessionID cookie. You don't own it. The server does. The server can and will change the cookie value at any time it chooses.

In particular, for security reasons, the Tomcat webapp server will change the cookie value when you had an existing session but switch to SSL/TLS. That's to prevent hackers from being able to access session data once the user starts working with secure data. The session object itself is essentially unchanged, but by changing the cookie value (which is is now being passed encrypted), no one can can use the old jsessionId to access session data.

If you want to invalidate a session, use the session.invalidate() method. If you have a cluster, you should make sure that the cluster has been configured to broadcast that invalidation to all nodes in the cluster. Likewise, if the session is being shared by multiple webapps (which isn't something I really recommend, incidentally).

[David Balažic]

Tim Holloway wrote:
You should never mess around with the jsessionID cookie.

I don't.

If you want to invalidate a session, use the session.invalidate() method.

Yes, that is what my code does.

If you have a cluster, you should make sure that the cluster has been configured to broadcast that invalidation to all nodes in the cluster.

No cluster.

Likewise, if the session is being shared by multiple webapps (which isn't something I really recommend, incidentally).

It isn't shared.