Can multiple browser instances corrupt data in memory?

Question

I wrote an ASP.NET app where it asks for a key value, and then the app fetches data from an API call and stores it in a class. Then I use the class data to populate browser controls.

So far, so good.

When the user likes what he sees, he clicks a button "UPDATE", and the class data is used to update the database. Then, the app clears the browser controls and all the class properties, and we start all over again from the top.

When a new key is entered, I know the controls and class are null before the API call. I have verified that.

Is it possible in memory, that if a user has multiple browsers open all running the same app, that I could have allowed class data from one browser to show up in another app instance and its class?

Is there anything I can look for in my code?

I'm fishing here. Here's the symptom:

A record was updated this morning using Key 1, and then hours later a different record was updated using Key 2, but half that data had the same contents from Key 1. Yikes!

Answer 1

Ok, as noted, I would look at session() values.

Remember, session is shared to the one user, and ALSO shared if they have 2 or 3 copies of the browser open!

So, session is global to the ONE user, and NOT per page.

So, you have to be careful. Say you have a grid row click, and based on that row click, you save the PK id in session, and then jump to the next page to view or edit say the hotel. (rather common to use session to pass some values to the next web page).

So, what happens if a user now opens up another browser, goes to the grid to select a hotel, and that 2nd copy then jumps to the hotel edit page also?

Well, now you have 2 pages open, each looking at a hotel, but the session("HotelID") is now set to the 2nd browser, but all of the code on the first browser window is open to a different hotel, but code behind ALSO uses that session("HotelID") to run the code logic on that page.

So, say your about to buy a house on line. If you use session("HouseID") and they launch another copy of the browser, and select another house, and go back to 1st browser and click buy house, that code behind BETTER NOT use session("HouseID"), else they will have just purchased the wrong house they are viewing!

So, session = global to the one user, and global to ALL pages open, even with separate copies of the browser.

Viewstate = per page. Of course you can't use viewstate to "pass" values to another page.

What the above means is that I OFTEN on first page load transfer any important session values (such as Hotel ID (pk) to viewstate. That way, then multiple pages can be open at the same time.

So, I often use session() to pass values around to the next page, (since placing such PK values in the URL is not only ugly, but often is a HUGE security risk).

And so is placing PK id into a hidden field or text box on the form - since a user can hit f12 to launch browser debug tools and CHANGE those PK values!

So, as a general rule, I never expose PK id values to the client side browser. My simple excpetions are say small combo boxes or drop down pick lists.

However, for any main reocrd editing on a page, then PK values are not seen, nor ever displayed in plain text on such pages. Nor are such values even placed in hidden fields.

So, there are 2 solutions to above. One solution is to generate a incremetning key value, and append that to the "id" for the given page. Thus you have a hidden field with some number like 1, then 2, then 3 and so on. That number is incremented each time, and then in code behind you append the pk value to session(). So, for a pk hotel id of 2222, then in session we store 2*2222.

This is secure, since if a user changes that firt prefix number, they simply not get a valid session "key" I'm using, and the worse is they would get an existing page they opened, but NOT other users data.

So, if you use session() to persist any values, then yes, then multiple web pages open will most certainly step and stomp on top of each other, since session() is per user, and not per web page.

Viewstate is "reasonable" secure, and while viewstate values are persisted in the browsers viewstate (client side), they are encrypted, and not in plain text. (given that viewstate travels up and down during post-backs, then they have to be kept small).

So, in most cases, PK values can be used in viewstate. However, as noted, depending on how secure you site needs are, then using a session() + some key value is the better solution, since then you NEVER have to expose database PK values used for editing to the client side browser code. And this also includes row clicks on a GridView, or listview (you use the server side managed datakeys() collection for this VERY reason (to not have to include PK row id values in a grid row click to select a record to work on).

So, yes, I would look close at any session() persisted values, since they are shared among all browsers open - even if you open Edge and FireFox, the values will be shared between the 2 browsers open when using session() values.....

Answer 2

You don’t specify how you tie memory to a browser instance.

I assume you use session. Session is tied to a cookie. Depending on how the new instance is created it may share the cookie (opening multiple tabs always shares the cookie).

if you did something like a static variable or a cache, then all browsers for all users share the same memory.