By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,062 Members | 1,358 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,062 IT Pros & Developers. It's quick & easy.

Different same machine browser sessions intefering with each other with Forms Authentication and asp.net 2.0

P: n/a
Hi All. I found several threads about this specific issue here, but
could not find a solution to my specific problem. Most of the threads
suggested that there would be a difference between launching two
separate IE processes and starting two windows in the same IE process
(e.g. Control-N). However, I am having this problem with the two
separate IE processes. Here is my situation:

We have an asp.net 2.0 app that uses formsauthentication. There is a
login page where the user authenticates; once authenticated, we store
the user object in a session variable and display the correct
information for the given user. There is a logout link that ends up
running the following code:

System.Web.Security.FormsAuthentication.SignOut()

I can open up two separate IE processes on the same machine and log in
as two different users. Each user will see the data relevant to that
user. However, if I log out from one of the user pages, the other user
will also be logged out! When the other user hits refresh (either from
my app or using the IE button), the user will be redirected to the
login page. So somehow the logout of one user is interfering with the
other one. I think there are other symptoms of one session interfering
with the other, but this is the only one I can reproduce right now.

Does anyone have any idea how I can fix or work around this problem? I
tried messing with the local IE cookie settings and it didn't make a
difference. I also edited the web.config file to make the app run in
cookieless mode. It definitely turned out (e.g. I saw new IDs in the
URL) but the same problem occurred. I don't know what else to try at
this point. Thanks in advance.

thanks,
Bob

Dec 11 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
most likely a bug in your code. you are probably storing session is a vb
module, causing it to be shared across requests

-- bruce (sqlwork.com)

bo************@qrm.com wrote:
Hi All. I found several threads about this specific issue here, but
could not find a solution to my specific problem. Most of the threads
suggested that there would be a difference between launching two
separate IE processes and starting two windows in the same IE process
(e.g. Control-N). However, I am having this problem with the two
separate IE processes. Here is my situation:

We have an asp.net 2.0 app that uses formsauthentication. There is a
login page where the user authenticates; once authenticated, we store
the user object in a session variable and display the correct
information for the given user. There is a logout link that ends up
running the following code:

System.Web.Security.FormsAuthentication.SignOut()

I can open up two separate IE processes on the same machine and log in
as two different users. Each user will see the data relevant to that
user. However, if I log out from one of the user pages, the other user
will also be logged out! When the other user hits refresh (either from
my app or using the IE button), the user will be redirected to the
login page. So somehow the logout of one user is interfering with the
other one. I think there are other symptoms of one session interfering
with the other, but this is the only one I can reproduce right now.

Does anyone have any idea how I can fix or work around this problem? I
tried messing with the local IE cookie settings and it didn't make a
difference. I also edited the web.config file to make the app run in
cookieless mode. It definitely turned out (e.g. I saw new IDs in the
URL) but the same problem occurred. I don't know what else to try at
this point. Thanks in advance.

thanks,
Bob
Dec 12 '06 #2

P: n/a

bruce barker wrote:
most likely a bug in your code. you are probably storing session is a vb
module, causing it to be shared across requests

-- bruce (sqlwork.com)
Hi Bruce. Thanks for your response. I'm not sure exactly what you mean
by "you are probably storing session is a vb module". We have a C# app.
First of all, we are using forms authentication, e.g. calls to
SetAuthCookie (and the logout call quoted above). How could this be a
bug in our code, the forms authentication is what's storing the state
itself, right? How could one forms authentication logout log out the
other one? Are you saying that maybe there's some web.config setting
wrong that controls forms authentication that we should change? We have
some other application session state that we store in the Session built
in usercontrol variable. Is this wrong?

I also replicated this in the .net 1.1 version of our app.

thanks,
Bob

Dec 12 '06 #3

P: n/a

bo************@qrm.com wrote:
bruce barker wrote:
most likely a bug in your code. you are probably storing session is a vb
module, causing it to be shared across requests

-- bruce (sqlwork.com)

Hi Bruce. Thanks for your response. I'm not sure exactly what you mean
by "you are probably storing session is a vb module". We have a C# app.
First of all, we are using forms authentication, e.g. calls to
SetAuthCookie (and the logout call quoted above). How could this be a
bug in our code, the forms authentication is what's storing the state
itself, right? How could one forms authentication logout log out the
other one? Are you saying that maybe there's some web.config setting
wrong that controls forms authentication that we should change? We have
some other application session state that we store in the Session built
in usercontrol variable. Is this wrong?

I also replicated this in the .net 1.1 version of our app.

thanks,
Bob
The problem ended up being that our call to SetAuthCookie passed in
true for the parameter to create a persistent cookie, I changed it to
false and it ended up working. Hope this helps someone else. Thanks
everyone.

Dec 12 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.