0

I have a session variable: ID. Is there ever a possibility that two browsers on the same PC could share the same session variable and update it, therefore producing random results. I would expect there to always be two separate sessions with two separate sets of session variables.

I have researched this and I have come accross the following web page, which suggests that there are session locks to prevent this from happening:http://odetocode.com/blogs/scott/archive/2006/05/20/session-state-uses-a-reader-writer-lock.aspx. I have an ASP.NET application and there are random results suggesting that this could be happening.

I will produce some code if requested.

UPDATE 19:51 Tim Medora says: "two instances of the same browser type using the same session ID". Does this mean that if a user opens one browser and then closes it (because it takes too long to open) and then opens another browser (in another window) then the same session ID could be used and the session variables in window 1 are copied for window 2?

UPDATE 19:35 24/10/2012 Tim Medora says: "However there is a very real possibility of two tabs in the same browser, or two instances of the same browser type using the same session ID". Will the session information be separate in these cases. For example, if a user opens a browser and then closes it (before the response has loaded) and then opens the same window with a different set of session variables then is there a risk that session A and session B have the same session variables.

w0051977
  • 15,099
  • 32
  • 152
  • 329
  • 2
    Just to get some regular confusion our of the way: Two different browsers should not be able to share a session but two different tabs or windows of the same browser will share a session unless you use some special *private* mode (Now available in most browsers). – madth3 Oct 23 '12 at 18:27

2 Answers2

0

The possibility of a random collision is extremely low.

However there is a very real possibility of two tabs in the same browser, or two instances of the same browser type using the same session ID1. Session IDs may also be reused, adding to the confusion.

Does this mean that if a user opens one browser and then closes it (because it takes too long to open) and then opens another browser (in another window) then the same session ID could be used and the session variables in window 1 are copied for window 2?

Yes, the session ID may be reused and the same session may be active. I did a quick experiment with Chrome and I was able to copy a URL (which uses Session) to new tabs and new instances of the browser, and the same session stayed active.

However, the session variables are not copied for the new window; they are the same values.

Session Locking

Locking Session only means that two writers can't update it at exactly the same time. More specifically, a lock is placed on Session from the beginning of the request until the end of the request; only one write can alter it during that period. But that period of time is usually very small, and (while the locking prevents some issues) it doesn't prevent two different sources from altering the same data at different times.

Avoiding Collision

One way to minimize collision is to use unique session keys. Let's say a user (in the same session) opens two different records for editing. If you have a session key of "ActiveRecord", the probability for data corruption/mismatch is very high. However, if each page stores a unique key in a hidden field, that unique key can then be used to retrieve the appropriate value from Session, and each value can be manipulated discretely.

In other words, unique keys allow you to safely open two different instances of the same item at the same time. This does not prevent issues with two windows editing the same item at the same time. Though they will have separate keys, the end result will probably be undesirable when the data is committed.

1 - this seems to be the case in all modern browsers, but I can't definitively say that it is always the case. Would welcome a reference.

Tim M.
  • 53,671
  • 14
  • 120
  • 163
  • Thanks. I have added to my question based on your answer. Could you have a look? – w0051977 Oct 23 '12 at 18:57
  • Updated to answer your question. – Tim M. Oct 23 '12 at 22:50
  • Thanks. I am nearly ready to acccept. I have updated the question. Please would you review it? – w0051977 Oct 24 '12 at 18:39
  • In response to your latest question, if the response hasn't loaded at all, then no session ID cookie would be written to the browser. Since the cookie is the only way the server can identify a session, you would *probably* be issued a new session ID and a new session. That's making a lot of assumptions though, the biggest assumption being that the cookie hasn't been written. – Tim M. Oct 24 '12 at 19:05
  • I am not sure that i quite right because the page still attempts to load if the browser is closed? – w0051977 Oct 24 '12 at 19:14
  • The server would probably continue trying to fulfill the request, so it might start a session. If the browser is closed before the first response reached it, the cookie probably wouldn't be written. But remember that ASP.Net writes the session cookie immediately, so the only way this would work is if the first request was the long-running one. Like I said, this is all making a lot of assumptions. Do you have a specific case you are trying to accommodate? – Tim M. Oct 24 '12 at 19:18
  • Yes, I asked the following question a few days ago: http://stackoverflow.com/questions/12980123/asp-net-accessing-web-page-twice-from-client. The page in question is very large. – w0051977 Oct 24 '12 at 19:21
  • Okay, that clarifies a bit. The accepted answer is correct--you can't update session from one page while another page has it locked. But the requests are queued, so the once the first page releases its lock, the second page might update the session variables. That might be undesirable behavior. Again, if the first page hasn't received the session cookie, then the second page could start a new session. I suppose it's even slightly possible that the first page might end up with the second page's session. All things considered, this probably isn't behavior you want to rely on. – Tim M. Oct 24 '12 at 19:32
  • BTW, if you need application-wide synchronization, you can use a SQL Server named application lock. These should be used with caution, but you can synchronize access across multiple sessions and even multiple servers. – Tim M. Oct 24 '12 at 19:34
  • I am just trying to prove that what you say in your forth comment can happen. It is underireable. When does the first page release the lock? Thanks. – w0051977 Oct 24 '12 at 19:38
  • The lock is taken very near to the beginning of any request which uses session, and released very near the end of the request. For practical purposes, it is for the duration of the request...in actuality, I think there are a few rapid steps which occur before/after locking. The incoming request goes through a few layers before coming to the handler, which states whether or not it needs session data. – Tim M. Oct 24 '12 at 19:54
  • Ideally it would be helpful to see an example where session state is shared,possibly by mistake. – w0051977 Oct 24 '12 at 20:14
  • What happens if the ASP.NET process is recycled during a request? Sorry for all the questions. I am still unclear. – w0051977 Oct 24 '12 at 20:23
  • Recycling the process will end any active requests and the session. If that is a potential problem, you can either disable recycling or schedule it for specific time(s). – Tim M. Oct 24 '12 at 20:52
  • I have asked a related question here: http://stackoverflow.com/questions/13057357/asp-net-process-recycling-and-session-variables#13057357. Can you take a look? – w0051977 Oct 24 '12 at 20:55
0

I faced similar situation recently. In create user screen, multiple addresses can be entered for the user. Initially I used session for storing addresses. Since session is shared across browser tabs, functionality didn't work well. And also I realized storing data in session is not a good approach due to various reasons like overhead in maintaining session state in webfarm scenario, etc. So, I had to switch back to DOM manipulation (since its mvc application) to store addresses. If it is web forms, viewstate might be alternative for session.

As mentioned in already posted answer, it can be achieved through sessions by using unique key per request i.e., in my case, storing addresses in session[userid] or you can use any random key to hold the values and have hidden fields to persist that key across web requests. However, I was not convinced by other reason that they will not be cleared automatically when user closes the tab.

Sunny
  • 4,765
  • 5
  • 37
  • 72