Re: Session-specific Auth Cookie

When I see problems like this, it often has to do with confusion between a
browser window and a browser process and how session cookies work.

IE (and probably Firefox it sounds like) will share session cookies across
the entire process. Here, a "session cookie" is the kind of cookie that is
not written to disk. It is kept in memory by the browser process and "goes
away" when the process terminates.

A browser process can have multiple windows though. You see this all the
time when you do ctrl+N in IE or right click "new window". A such, those
windows will all send the same cookies back to the server. Since session
state in IE is cookie based, all of those browser windows will use the same
session state.

However, it is also possible to have multiple IE processes running at the
same time. These will not share session cookies.

I agree with Dominick that using a tool like Fiddler or a plugin like
ieHttpHeaders for IE (or the built in header stuff in Firefox) is a good way
to see which cookies an invidual browser window is receiving and sending so
you can see what's going on.


Joe K.

"Matt Braun" <mattb308@xxxxxxxxxxxxxxxx> wrote in message
I agree and what you describe is the behavior I was expecting - that each
session would have its own auth cookie. My code (neither the web app nor
custom security provider) doesn't write the cookie though since I'm
on ASP.NET's forms authentication to handle that. As such, I'm uncertain
I'm not experiencing the behavior we both expect.

Further ideas on why ASP.NET would be writing the cookie in a way that
it shared? If I look at the cookie in FireFox is does indeed identify
as a "Expire At End Of Session" so, at least to that degree, it seems to
marked as Session cookie.

"Dominick Baier [DevelopMentor]" wrote:


this sounds like you are persisting the cookie on the harddrive.

Usually the auth cookie is a temporary cookie per session. However - if
start a new IE instance using ctrl+n e.g. they share the temporary

Dominick Baier - DevelopMentor

I'm testing an ASP.NET 2.0 Application that uses Forms Authentication,
a custom Security Provider, and the built-in asp:Login server control.
I've discovered that if I open two or more separate instances of a
given browser (ie; 2+ instances of IE or 2+ instances of FireFox) and
log in to one browser using one set of credentials and the other using
another set that spordically the browsers begin sharing the
information about who is logged and, thus, I can only effectively be
logged in as one person at a time from a given machine.

Generally - in IE - if I only use the buttons in the application to
move around then I'm okay but if I hit the browser's back button it
tends to change me over to the credentials of whichever user I most
recently loaded a page for.

In Firefox, the behavior is a bit different - it consistently shares
the information across all instances no matter if I'm clicking through
only using buttons/links in the app or if I'm using my back button.

Naturally, if I have FireFox and IE open at the same time, they don't
share the data and I *can* run two separate logged in users from the
same machine. Based on this behavior, I think that what is happening
is that the .ASPAUTHX cookie is being shared across my sessions in any
given version of browser.

1. Can anyone confirm that what I'm seeing is expected behavior?
Should .ASPXAuth cookies (for a single application) be shared globally
across all instances of given browser?

2. Is it possible to enforce .ASPAUTHX cookies to be session-specific
to allow for having two instances of IE open at the same time but
logged in as two different users?


Relevant Pages

  • Re: _SESSION weirdness behind a NAT firewall/router: bug?
    ... that the 'sess_deleted' file is actually being used as a session ID. ... force the cookie to expire. ... Any $_SESSION values introduced by one browser become part of the ... I re-load the non-logged-in index page in Opera. ...
  • Re: php session without cookie useage
    ... >>> browser or the application to maintain the state if needed. ... >>> transfer a session key created on login to subsequent pages via a POST ... >>> browser via a cookie or via POST or GET. ... > That may block legitimate users using a round-robin proxy (different ...
  • Re: Is Session Always Cleared?
    ... If the first user closes his browser after he is finished, the session cookie is forgotten. ...
  • Re: Detecting loss of session
    ... > a request. ... From what I've read on session cookies ... > sending) them as soon as they expire, not when the browser is closed? ... If you don't set the expiration on a Cookie, ...
  • Re: Cookies , Session Which is Better ? and Global.asa Question
    ... YOU SHOULD NEVER STORE PERSONALLY IDENTIFIABLE INFORMATION IN A ... If you needed to store personal information in a cookie use non ... impossible - its much harder for me to hijack session information from ... The average time a session lasts is 20 mins. So, when your browser ...