Session persistance in browser tabs

Hello,

 

 

What's the actual failure? Are you using cookie insert persistence? Is the client sending a request without the BIG-IP persistence cookie when multiple browser tabs are open? Where does Java come into play if the issue is with multiple browser tabs? If you switch to source address persistence as a troubleshooting step, is the problem resolved?

 

 

Aaron

Hi,

 

 

The issue is even without the BigIp as soon as you open a second tab it creates a new session cookie. When you go back to the first tab and do a query you get date from the second tab,

 

 

Sorry should have explained it better.

 

 

Wynand

Is this an accurate summary of the scenario?

 

 

Without the BIG-IP, a client opens one tab and accesses the application. The app creates a session and sends a session cookie in the response. The client sends further requests in the initial tab and the application works as expected based on the single session. The user then manually opens a new tab and accesses the same application. At this point the client doesn't send the original session cookie. The application attempts to prompt the user to start a new session.

 

 

Up until now is this all expected, working behavior? Now the client goes back to the first tab and they get the second tab's session details?

 

 

Is the above an accurate summary of the issue? I'd expect the cookies to be shared across tabs in both IE and Firefox, so I'm not sure if the above scenario is possible. Also, where does Java come into play?

 

 

Can you use Fiddler for IE or LiveHttpHeaders for Firefox along with the Java debug console to track exactly what the client sends and receives when a failure occurs? Once you get an accurate understanding of the failure without the BIG-IP you can consider whether it's possible to fix it with an iRule or other configuration on the BIG-IP.

 

 

Aaron

I'd expect the cookies to be shared across tabs in both IE and Firefox, so I'm not sure if the above scenario is possible.

 

 

Have to agree with hoolio, the browser should be sending the app cookie if the hostname is the same for both tabs, and looking at the transaction stream should reveal what's going on. If the client is not sending the cookie, there's nothing LTM can do to intervene and correct the situation.

 

 

/deb

One place I have seen cookies not being sent is when a request is spawned from the browser through Java. And to complicate the troubleshooting, HTTPwatch didn't get this traffic as it wasn't originated from the Java client. It might be helpful to install an interception proxy and configure both Java and the browser to use localhost:8080 (or whatever port you configure the interception proxy on) to catch the requests. BURP (Click here) is a free for non-commercial use, lightweight and easy to use.

 

 

Aaron

I find Fiddler to be incredibly helpful for debugging that kind of thing, and it doesn't require you to modify any browser settings.

 

 

http://www.fiddlertool.com/fiddler/

I spoke to the client and they were not to happy to do a SSL trace due to the fact that they are a bank but explained it like this :

 

 

1. Logon – Site sends cookie with Name: ASPNET_SessionId

 

 

2. Open new tab.

 

 

3. Navigate to site in new tab, now the ASPNET_SessionId is passed to the site because the site is the same

 

 

4. Logon again, cookie gets updated with a new session ID

 

 

5. Switch back to first tab and carry on navigating

 

 

6. From this point on the new session ID is being passed to the web site so navigation carries on as if it’s the second login, and not the first login.

 

 

 

Hopefully this makes more sense.

 

Thanks for the help.

 

Wynand

Hi Wynard,

 

 

What is the actual problem the customer is trying to address?

 

 

It sounds like the browser is working exactly as expected. There is no way to differentiate which tab or window of a browser originated a request using cookies. The browser will send the current value for the cookie assuming the cookie hasn't already been expired.

 

 

Did the tester log in on tab 1, open a new tab, log out and then log in as a different user before going back to the first tab? If so, what were they trying to prove? Wouldn't the app expire the user's session cookie and invalidate the session on the server if they logged out? If so, why would the new session ID still be valid on the server when they went back to the first tab and tried to navigate again?

 

 

I think it would help to get a clearer idea of what the issue is. But based on what you've mentioned so far, I'm guessing this is something that would best be fixed in the app itself.

 

 

Aaron

hoolio is correct; the browser will only keep one cookie for the site and present it no matter which tab is used to access the site.

 

 

There is one clever way around this, and that is to make the browser think that the two tabs have different sites. You could use iRules to add a fake random prefix to the hostname and strip it off before it sends the requests to the real servers. That would require a wildcard cert if you're doing SSL. Of course, it may not be OK for your users to see, for example, a hostname of h3852934510182.yoursite.com in their browser, in which case this wouldn't work.