[2005] Another Cookies Question - IE7 Tabs vs IE Windows

[MMock]

If I set a cookie in one tab of an IE7 browser, that cookie is available and valid in all the other tabs???

I don't know if this matters, but it seems strange to me. If I start my application in tab 1 and I log in, my login will set a cookie: Response.Cookies("MY_SESS")("session_id") = session_id. session_id is the key/identity of a new row just inserted into the database's usr_log table, meaning my credentials were validated and I am logged in.

I can go to a new tab and type the name of a page and all the query strings it needs. The first thing this page is supposed to do is make sure I am logged in. I am, but not in this tab. But it will let me go to the page and update the database.

If I go to a new browser window and type the name of a page and all the query string it needs, the page will say I'm not logged in.

I guess this won't cause any problems, it just surprised me. In a way, I am bypassing the login, because if normally I am supposed to go login->menu->page A, I can just go page A if I open a new tab in the browser window I've originally logged in through.

[MMock]

I do have a problem. Please tell me what you think about this.

The application I am currently working with was written in ASP for IE6.

The first change was that our office went to IE7. There were a lot of problems with "IE7 cannot display the webpage." I fixed some of those when I started working here, but my main role was to convert ASP to .NET. But the important thing with IE7 is the introduction of tabs.

When a user logs into our application, he can log in as two types of ids, administrator or user. A row is created for him in a table that keeps track of who is logged in. The identity of the new row is returned and a cookie is set which is used throughout the application to identify the type of user. So if the user created a new row with identity 99 that is the value of the cookie. This cookie value is retrieved throughout the application and looked up in the table to see what kind of a user it is, "user" or "adminstrator", to allow or deny functionality.

I hope this is clear so far.

Here's the scenario. I log into my app as user, and I create a row and a cookie. Let's say the value is 12443. I am limited to doing only certain functions. I open a new tab and log into my app as administrator and I create a row whose value is 12444 and I reset the cookie to this value, because tabs within the same browser window share cookies. Tab #2 has unlimited functionality. When I return to tab #1, my cookie value is no longer 12443 but has been updated to 12444. So now even though that tab is logged in as user it has administrator authority.

HELP!!!!!

I guess my main question is can I have two tabs logged in as different level users and keep track of them> Probably the answer is don't use cookies - use something else that the tabs don't share.

Thanks.

[MMock]

This is the other thing I was thinking, which would probably be the least amount of change to my application.

User opens IE and is in tab #1 and logs in as administrator. The code sees there is no value for the cookie so it approves the login and sets the cookie.

User opens tab#2 and logs in as user. The code sees there is a cookie and denies the login. The user is forced to open a new IE window in order to login a second time.

Do you know what my user will say about this? That it's more efficient to use tabs than windows. I can't see this. Is this a valid argument? Is there something I am missing about the merits of tabs??? He keeps saying turn off the cookie. He makes it sound like a light switch, not something I will have to spend hours analyzing and recoding.

[szlamany]

And you don't think that the cookie might get left with a value and then simply start denying access? Without a way to fix that?

[MMock]

And you don't think that the cookie might get left with a value and then simply start denying access? Without a way to fix that?

Close the browser?

[mendhak]

If I set a cookie in one tab of an IE7 browser, that cookie is available and valid in all the other tabs???

I don't know if this matters, but it seems strange to me. If I start my application in tab 1 and I log in, my login will set a cookie: Response.Cookies("MY_SESS")("session_id") = session_id. session_id is the key/identity of a new row just inserted into the database's usr_log table, meaning my credentials were validated and I am logged in.

I can go to a new tab and type the name of a page and all the query strings it needs. The first thing this page is supposed to do is make sure I am logged in. I am, but not in this tab. But it will let me go to the page and update the database.

If I go to a new browser window and type the name of a page and all the query string it needs, the page will say I'm not logged in.

I guess this won't cause any problems, it just surprised me. In a way, I am bypassing the login, because if normally I am supposed to go login->menu->page A, I can just go page A if I open a new tab in the browser window I've originally logged in through.

No, no, that's how browsers work. You are logged in to VBForums and are looking at the ASP.NET forum page. You open a thread in a new tab and are still logged in. Imagine if you opened a new tab and had to login for each tab. So the behavior you describe is perfectly normal.

[mendhak]

I do have a problem. Please tell me what you think about this.

The application I am currently working with was written in ASP for IE6.

The first change was that our office went to IE7. There were a lot of problems with "IE7 cannot display the webpage." I fixed some of those when I started working here, but my main role was to convert ASP to .NET. But the important thing with IE7 is the introduction of tabs.

When a user logs into our application, he can log in as two types of ids, administrator or user. A row is created for him in a table that keeps track of who is logged in. The identity of the new row is returned and a cookie is set which is used throughout the application to identify the type of user. So if the user created a new row with identity 99 that is the value of the cookie. This cookie value is retrieved throughout the application and looked up in the table to see what kind of a user it is, "user" or "adminstrator", to allow or deny functionality.

I hope this is clear so far.

Here's the scenario. I log into my app as user, and I create a row and a cookie. Let's say the value is 12443. I am limited to doing only certain functions. I open a new tab and log into my app as administrator and I create a row whose value is 12444 and I reset the cookie to this value, because tabs within the same browser window share cookies. Tab #2 has unlimited functionality. When I return to tab #1, my cookie value is no longer 12443 but has been updated to 12444. So now even though that tab is logged in as user it has administrator authority.

HELP!!!!!

I guess my main question is can I have two tabs logged in as different level users and keep track of them> Probably the answer is don't use cookies - use something else that the tabs don't share.

Thanks.

To be blunt, whoever did design the application that way didn't have a good understanding of how browsers work. When a cookie is written by a page to the client's browser, it gets written on a per-domain basis. The page is client-agnostic. This means that it doesn't care if it's being displayed on a PC browser, a mobile browser, an embedded device, a cyborg's retina or in a console application via telnet.

To illustrate further from the previous example, all tabs in IE that have www.vbforums.com on it will show you as logged in. As long as that cookie is there, you will always be logged in. If you are on VBF Tab #9 and you logout there, and then login as another user, when you refresh the other tabs, they will all show you as the newly logged in user.

[mendhak]

This is the other thing I was thinking, which would probably be the least amount of change to my application.

User opens IE and is in tab #1 and logs in as administrator. The code sees there is no value for the cookie so it approves the login and sets the cookie.

User opens tab#2 and logs in as user. The code sees there is a cookie and denies the login. The user is forced to open a new IE window in order to login a second time.

Do you know what my user will say about this? That it's more efficient to use tabs than windows. I can't see this. Is this a valid argument? Is there something I am missing about the merits of tabs??? He keeps saying turn off the cookie. He makes it sound like a light switch, not something I will have to spend hours analyzing and recoding.

That logic will always present a login page to the user. Think about it. You're including code to look for a cookie and then deny login. So everytime the page is loaded or refreshed or the user clicks on a link, that check will occur and the user will be denied login. Including when the user successfully logs in!

You will need to make a stand and mention to the user that they're not always right. This is how browsers and the world wide web works. There isn't a clever way around it either. One login at a time per browser. So you could tell them to use firefox for their 'other' login because the cookies between IE and FireFox don't interfere with each other.

[MMock]

So, if the user opens tab#1 and logs in as administrator and opens tab#2 and logs in as user, when he returns to tab#1, the next time he presses a button that does a postback, the code needs to realize he's changed from admin to user in the browser (all tabs) and "reload" the application so it is presenting the more limited version of the application. Is this correct?

My whole issue with the way our application was designed (and maybe this is just something I have to get over, I don't know if it's poor design or not), is that we run www.ourwebsite.com/application/login/login.asp. There are about six different types of users that log in, and the application is just a little bit different for each login. There's a lot of code sharing, but also a lot of logic - if user type is admin then render this button else don't. Or maybe make admin's button Update while user's button is just View. The difference between vbforums and our application is in vbforums you get the same functionality (as far as I know, but maybe a moderator does have more than I?) so nothing needs to be re-rendered. So if I have adminmenu.asp and usermenu.asp that get loaded once, I'm not sure how to detect the switch and re-render the application appropriately (our application is currently three ASP frames, a menu, a header and the work area - when I get a postback or load a new page, it's only the work area that changes. This work area is a mix of asp and asp.net pages, as I migrate).

I'm not sure I believe the part you said about how I will be denying login. Isn't the cookie there until the entire browser closes? I discovered during my first couple weeks on this job that I was getting duplicate login errors until I closed the whole browser because the cookie was still hanging around from my first login. How will (re)loading a page or clicking a link not find the cookie?

Well, I have a conference call this morning between my customer, myself and our boss so anything else you can add before 10:00 a.m. EST would be *greatly* appreciated!

Thanks!

[mendhak]

It depends on the type of cookie. A session cookie should go away when you close the browser, but a persistent cookie will still be there the next time you open the window. From what I've been reading in this thread, it sounds like you're writing a persistent cookie.

If you were in fact talking about a session cookie, then you would be checking for the session variable. And you'd have to do this on every page - check for a session variable, deny login.

VBF too has something similar to what you're saying. I am a moderator and I see extra menu options and buttons in several places. The main way to deal with this is to always check (on page load) for a user's permissions. I'm pretty sure your application does that anyways, so if the scenario you described occurs (admin relogs in as non admin), the rendering should notice that it's a nonadmin type user and render the controls accordingly.

[MMock]

If you were in fact talking about a session cookie, then you would be checking for the session variable. And you'd have to do this on every page - check for a session variable, deny login.

It's not done on every page currently in ASP. I don't know if sometimes he forgot but there's somewhat of a pattern that if the page can do an update/insert to the database, it checks. I'm not sure it's 100% consistent. And yes, it's a session cookie. Sorry if I wasn't clear. I guess I didn't know there was a such thing as a persistent cookie .

VBF too has something similar to what you're saying. I am a moderator and I see extra menu options and buttons in several places. The main way to deal with this is to always check (on page load) for a user's permissions. I'm pretty sure your application does that anyways, so if the scenario you described occurs (admin relogs in as non admin), the rendering should notice that it's a nonadmin type user and render the controls accordingly.

Except that given my frames, the menu and the header don't post back when you change pages so there's the whole issue of logging in as admin, getting adminmenu.asp, then opening a new tab and logging in as user. The main pages would know because they are what is changing. But how would I update the menu? I guess what would happen is you'd pick a link off the admin menu and that page would have to check if you're really admin. The only pages that currently have the "if usertype=admin then ... else ... " check are the ones that are truly shared, that know they are shared. But we have a scenario where a user can click on an admin menu option if user logged in on first tab, admin logged in on second tab. Of course, only employees of our company who know the admin password would be able to do this. It's all kind of confusing, but I'd really like it to make sense. It's just how I like my software to be!

Can I just ask, you said the original developer didn't know how browsers work. Well, that may have been when you thought it was a persistent cookie. Given he was in an ASP/IE6 environment, it was probably okay? There just should have been more testing and analysis when we went ASP/IE7. But there may have been no programmers on staff then and I'm sure the users had no clue.

Thanks again!

[mendhak]

Yes, it's more difficult in a frames environment. The menu frame most likely has its links targeting the main frame, so that menu page itself doesn't refresh. Which means that you could potentially have a user who has an admin interface open, who then logs in as nonadmin on another tab, comes back to the original tab and is restricted on the main frame, but still has the admin menu options available to see. Unfortunately, that is what you get for using frames (and also serves as an argument to why frames shouldn't be used). The only way to overcome it would be to add a bit of 'javascript' to the other pages which query a page that returns a session variable once every x seconds that in turn determines whether the menu page needs to refresh or not. So it's going to cause a complexity overhead.

[mendhak]

Can I just ask, you said the original developer didn't know how browsers work. Well, that may have been when you thought it was a persistent cookie. Given he was in an ASP/IE6 environment, it was probably okay? There just should have been more testing and analysis when we went ASP/IE7. But there may have been no programmers on staff then and I'm sure the users had no clue.

Hmm... well, assuming the developer had never used Mozilla/Opera, which have had tabbed browsing since 2000. Yes, there should have been more testing/analysis for IE 7, but to be completely honest, this situation shouldn't have arisen at all. The original implementers of the application may have thought that using frames instead of included pages would have been quick and easy, but it has now given you this maintenance nightmare which you have to deal with - all due to tabbed browsing! It has suddenly made your application become susceptible to inconsistent state changes across tabs. I think the problem now is more about frames than it is about sessions and cookies. If you use a normal ASP.NET page with a menu/header control, then your Master Page takes care of the authentication and helps the other controls display certain buttons or menu items as per the user's role. This then makes the application independent of what is going on in other tabs as it will always display what it needs to display.

[MMock]

Yes, it's more difficult in a frames environment. The menu frame most likely has its links targeting the main frame, so that menu page itself doesn't refresh. Which means that you could potentially have a user who has an admin interface open, who then logs in as nonadmin on another tab, comes back to the original tab and is restricted on the main frame, but still has the admin menu options available to see.

Well it's nice to know you completely understand what I am describing! Thanks!

[MMock]

Hmm... well, assuming the developer had never used Mozilla/Opera, which have had tabbed browsing since 2000. Yes, there should have been more testing/analysis for IE 7, but to be completely honest, this situation shouldn't have arisen at all. The original implementers of the application may have thought that using frames instead of included pages would have been quick and easy, but it has now given you this maintenance nightmare which you have to deal with - all due to tabbed browsing! It has suddenly made your application become susceptible to inconsistent state changes across tabs. I think the problem now is more about frames than it is about sessions and cookies. If you use a normal ASP.NET page with a menu/header control, then your Master Page takes care of the authentication and helps the other controls display certain buttons or menu items as per the user's role. This then makes the application independent of what is going on in other tabs as it will always display what it needs to display.

Okay...but the application CAN'T be independent of what is going on in other tabs if another tab can completely change the permissions of the logged in user, right???

I think I understand everything else.

I guess it just won't work too well until this is all redesigned.

The silver lining is probably that our in-house staff can be told how it works and to use it the right way (i.e., if you want to log in as a different user open a new IE window or else be ready for strange behavior like disappearing or appearing functionality) and our other customers probably don't even run more than one instance, but I'll find that out in 10 minutes when we have our conference call.

Thanks for all your analysis. As a reward, I hope I can give you the rest of the week off by not asking any more questions for a while...

[MMock]

Here's what came out of our conference call. It's a question. Is there any way you can have two different types of users logged into your application in two different tabs of the same IE browser window? If a cookie is shared across all tabs there must be something else I can use that's not shared that will keep the flavors of the application separate for each distinct tab?

My user asked if we can just forget about relying on IE7 to tell us who is logged in. I'm having trouble visualizing this. How can I know from page to page that someone is logged in and what functionality he should be permitted without having a database row and a way to look up the row (currently it's the cookie value)?

Thanks very much!

[MMock]

And maybe someone else can advocate my user's point of view to help me understand. He said he needs tabs, he can't use separate IE windows. I said I don't understand that. He said I don't need to understand it (which was a rather demeaning remark, if you ask me). So I'm just supposed to accept "the customer is always right"? I'm a computer user too, and I don't see much difference between alt-ctrl or alt-tab to switch between processes, or clicking on a tab or an icon in my taskbar.

[mendhak]

Okay...but the application CAN'T be independent of what is going on in other tabs if another tab can completely change the permissions of the logged in user, right???

I think I understand everything else.

I guess it just won't work too well until this is all redesigned.

The silver lining is probably that our in-house staff can be told how it works and to use it the right way (i.e., if you want to log in as a different user open a new IE window or else be ready for strange behavior like disappearing or appearing functionality) and our other customers probably don't even run more than one instance, but I'll find that out in 10 minutes when we have our conference call.

Thanks for all your analysis. As a reward, I hope I can give you the rest of the week off by not asking any more questions for a while...

Right... the application gets affected by changes done in another tab or in another window of the same browser. That means two tabs in IE 7 = two windows in IE 6.

In regards to the MasterPage though, it doesn't care what is happening in other tabs. Understand that each .aspx or .asp page is requested by the browser. This means that each time a user clicks on a button or a link, it is sent as a request to the server: "Please give me abc.aspx and oh, by the way, here are some form variables that will help you determine what HTML to send back. And here are my cookies so you can identify me."

In other words, a browser is simply a sophisticated download/upload tool that knows what to do with HTML markup. And cookies. It's just that the tabs and windows could possibly change these values going back to the server.

[mendhak]

Here's what came out of our conference call. It's a question. Is there any way you can have two different types of users logged into your application in two different tabs of the same IE browser window? If a cookie is shared across all tabs there must be something else I can use that's not shared that will keep the flavors of the application separate for each distinct tab?

My user asked if we can just forget about relying on IE7 to tell us who is logged in. I'm having trouble visualizing this. How can I know from page to page that someone is logged in and what functionality he should be permitted without having a database row and a way to look up the row (currently it's the cookie value)?

Thanks very much!

Nope. A login in one tab will overwrite the login in another tab. In other contexts, the cookie created by one tab will overwrite the cookie created in another tab.

Your application relies on the existence of cookies on the user's machine to know who is logged in. The browser tabs fall under the same application and write to the same cookie.

[mendhak]

And maybe someone else can advocate my user's point of view to help me understand. He said he needs tabs, he can't use separate IE windows. I said I don't understand that. He said I don't need to understand it (which was a rather demeaning remark, if you ask me). So I'm just supposed to accept "the customer is always right"? I'm a computer user too, and I don't see much difference between alt-ctrl or alt-tab to switch between processes, or clicking on a tab or an icon in my taskbar.

He wants to be logged in as two application roles at the same time from the same browser (but separate tabs) but it's not possible. He will either need to logout and re-login when he needs to, or use IE + Firefox, with IE as admin and FF as nonadmin or vice versa.

[MMock]

He wants to be logged in as two application roles at the same time from the same browser (but separate tabs) but it's not possible. He will either need to logout and re-login when he needs to, or use IE + Firefox, with IE as admin and FF as nonadmin or vice versa.

He *could* use two IE windows, instead of one IE window and one FF window, right? It's a session cookie, so each of the two IE windows would have its own?

And not that I would want to do this, but couldn't a query string be used instead of a cookie? I could log in using tab1, create a database row as admin, and just pass the identifier all around in a query string. Then I could log in using tab2, create a second db row as non-admin, and pass the 2nd identifier around in a query string. Each tab would know I was someone different? Recall I did say I do not want to do this...just curious if it would work.

[mendhak]

The cookie will be shared across the IE windows. Hence, 2 windows = 2 tabs.

A querystring could be used but defeats the entire purpose of logins and security.

[MMock]

The cookie will be shared across the IE windows. Hence, 2 windows = 2 tabs.

Really. Once again, something I did not know. Thanks.

A querystring could be used but defeats the entire purpose of logins and security.

Okay. Thanks.