Prevent multiple browser sessions on a single server session

Question

I am sure that we all worked or know about web applications (especially in the enterprise) that are closely related to the server session. In these cases, it is possible that the session will be corrupted if multiple browser sessions are open and the same server session cookie is used. We looked at all the options and found a better way forward to discourage the use of multiple browser sessions that share the server session cookie.

This is really a problem when the user runs New Window - Ctrl+N in IE or the equivalent of the "duplicate tab" in other browsers. In essence, we get two active browser sessions that use the same cookies.

So, to prevent this (as this is likely to be unintentional), I intended to introduce some kind of warning system to prevent this behavior. Now our code does a lot of concurrency checks to ensure data integrity, but there may still be problems with data corruption.

My solution, finding that the general answer was “impossible,” was to rely on AJAX to send pings and measure the time between them. So, we have a general rule: we are “ping” with a certain interval, and if the delta between the last ping in the current ping is less than the ping duration, we know that we have several active browser sessions on the same server session.

So where Pf is the ping frequency; Pc - current ping; and Pl is the last ping, then we have an error when Pf > (Pc - Pl) .

  p1 p2 p3 p4
 TAB1 0 ----- | ----- | ----- | ----- | ---...
                  :::
                  : p1: p2: p3 p4
 TAB2 0 ----- | ----- | ----- | ----- | ---...
      ^ ^ ^ ^ ^ ^ ^ ^ ^
                   Deltas

  ---- + --- + ------------
 TAB |  P |  Delta (Pc - Pl)
 ---- + --- + ------------                 
  1 |  1 |  5
  1 |  2 |  5
  2 |  1 |  2.5 -Error
  1 |  3 |  2.5 -Error
  2 |  2 |  2.5 -Error

Now, if there is network congestion or other factors, then the delta will be more than the frequency, excluding false alarms.

We have a problem if two tabs are open at the same moment. But since the ping frequency is the frequency at which requests are executed, and not the guaranteed elapsed time, we can assume that soon both browser sessions will begin to go out of sync.

In the example, I have a ping frequency set every 5 seconds. If there are 100 concurrent users, we look through ~ 20 requests / second for the ping servlet / HttpModule. To minimize unnecessary network traffic, I thought the ping frequency would decay over time until a maximum of 20 peaks per second was reached. This will be ~ 5 requests / second with 100 concurrent users. However, this is a compromise, as this will cause a delay in detection. However, as soon as detection occurs, the frequency is reset to 5 pins / second until resolution. (These numbers are given as an example: they will vary depending on the environment)

To minimize concurrency and scalability issues, the last ping timestamp for the session should be stored in the session itself. This will allow any distributed session technology to maintain session availability through the JVM or application domains without our ping service to be aware of.

I am trying to determine if this is the right approach if I am in the world of pain. Any experience related to the problem will be helpful.

EDIT: I know this sounds like tape help, but that means it will be a long lasting measure until we can rip off the violating library.

Answer 1

I worked on a single-window web application many years ago (pre-dating "Web 2.0"). We just launched a new window without any toolbars (without the "Back" button, etc.) and disabled the right-click. We took care of creating a very convenient navigation system. This was enough to prevent almost all random repeat views. This is an intranet application; obviously, I would never recommend doing something like this on a common website.

Personally, I don't like the sound of the ping detector. I would just make sure that no data corruption will ever happen. Several browser sessions are no excuse for this ... although I understand how this can be problematic. But if you want to add a ping detector on top of perfectly working code, it can serve as a useful reminder for the user.

You can add a unique token at the end of each link. If a unique token is used several times (for example, opening a new window, bookmarking, back, forward), then the request may be rejected. With proper tracking, you can ensure that you can never go from one page to another without using a valid path. This approach is more reliable than ping (since it is controlled by the server), but can lead to a very annoying perception of users.

Not enough: fix your application so as not to damage the data. I know that this cannot be a trivial thing, and I do not want to cover it. Implement pings, etc. May help fix the problem, but I guarantee that if something can go wrong, in the end. :-)

Answer 2

Which browser do users use?
We decided on a data corruption solution when IE8 came out and provided NoMerge .

Answer 3

You can achieve this using javascript and cookies created on the client, combined with the fact that the browser window / DOM name must be unique. Very easy to use without modifying your site.

1) When loading the page for the first time, check if a session cookie exists and if not, then create a session cookie (do not set an expiration date) with a unique name and value (some kind of code). Set the browser / home window name (NOT the name) with this cookie value.

2) For subsequent requests, you need to verify that the DOM window name matches the value of the cookie - if not redirected to the error page.

3) Remember to delete the cookie on the page to close the window by deleting the cookie.

This works because if you try to open a duplicate window, the duplicate window will not have the same DOM window name as the cookie value, and you can answer that fact.

Code example

 function CheckMultipleSession() { var existingCookieValue = getCookie("MySessionCookie"); if (existingCookieValue == null) { //first request so create cookie currentCookieValue = guid(); setCookie("SessionGUID", currentCookieValue); window.name = currentCookieValue; // setting DOM window name (this is key) } else { if (existingCookieValue != window.name) top.location = "MultipleSessionsError.htm"; } } 

Answer 4

My main concern will be whether it will be compromised when there is network latency. That is, any problem would probably arise from problems for which ping is commonly used.

Answer 5

If you really are bound and cannot fix the application to intelligently handle multiple instances of the browser using the same session, then yes, this is a sound approach.

For what it's worth, I used the same concept to enforce restrictions on concurrent license usage - so it will detect that multiple users are using the same “key”, which in your case is a session.

I would change your approach a bit and have a ping message containing the date / time of the client - so that you can not take into account all the network latency in your calculations.

Answer 6

Too late. But you can consider generating a random string on the server and sending it to the interface in a hidden form. Maintaining the last random key for a session in a user session object. Each time a user makes a request to the server, send this random key back. Check the random key in the browser with the saved in the session. If they do not match, you can tell the user that they should use a different window. Not very convenient, but will work.

Answer 7

A very simple solution that you may or may not use is a single page (for example, a single URL such as home.whatever) for an ajax application. If they request the same page a second time and already have a valid session, then you know that they have opened a new tab or a new window. Please note that you cannot distinguish this from an update.

Your decision is too complicated.