4

Everything in italics is the original post, edits below are non-italicized

I am writing in C# using ASP.NET 4.0. I am authenticating user credentials via SQL lookup and if valid I am storing the username in a session variable then redirecting the user back to the main page. Pretty simple.

if (!db.isValidLogin(userName, passWord))
    {
        //invalid login, show it!
        //just some code to tell the user invalid credentials
    }
    else
    {
        //show login successful!
        //update some items on the screen
        Session["username"] = userName.ToUpper();
        Response.Redirect("/");
    }

This is not yet over SSL as it's internal development at this point. When I use Chrome Version "25.0.1364.172 m" I am properly redirected and I am "logged in". My screen is representative of that by showing me my user name and allowing me access to features that authentication allows. When I use (32-bit) IE 9 Version "9.0.8112.16421" with the same server side code and procedure... When I do the redirect my session variable "username" is gone. In fact the session has a count of 0 for items. BEFORE the redirect the session variable is set and it is correct. I have the same results on a Windows Server 2008 R2 64-bit box and a Windows 7 64-bit box. I am using a single server hosting both IIS and SQL. I am not using a session server. I have traced it out... the code is running exactly as desired up until the redirect. Receiving credentials, executing my stored procedure to validate... setting the session variable before redirecting (I can see the session and the variable and the value is correct).. and then redirecting... and as stated, with Chrome it works EXACTLY as desired... with IE the session is lost on redirect. I have tried this as well with no success: Response.Redirect("/", false); So I'm convinced that something IE is doing, maybe with setting cookies on the client, that is causing a mismatch between the browser and the server session. Should I not be doing a response.redirect??? And if I do a response.redirect, how do I keep the session from resetting? Once again, keep in mind this doesn't happen when I use Chrome. Frustrating... Thanks for any help!

NEW INFO

After attempting to turn off IE caching per an answer... I decided to output the sessionID to the browser so I could see what it was.

The behavior is more direct that the login and redirect...

In IE simply refreshing the browser with F5 causes a new session to be created on the server. Each refresh I receive a NEW session ID.

Testing this with Chrome I do not get a new session ID unless I call session.abandon, timing out my session or closing and restarting the browser.

I was only calling session.abandon when the user clicked log out, but have commented out that code (just in case) to ensure that I'm not abandoning it on accident.

Somewhere between actual page refreshes IE is presenting itself to the server for a new session... ARGH.

For example: Chrome: Before login: myjuzrmccerk1t4eakcliq14 After login: myjuzrmccerk1t4eakcliq14

IE: Before login: unyebuc2ikac12xnhpssy0em After login: unyebuc2ikac12xnhpssy0em

Refreshes with F5 or Ctrl-R: one: ptjt42fjwzgdreyyyo3cmvrs two: s1hd5aatl5yexeuc125aqhst three: kbpflurcdcxubux3scmdm4k5

Update 2

I have changed the site to use "State Server" for the session and started the appropriate service... There is no change in behavior.

ANSWER

Since my rep is low.. .this won't let me answer my own question for another 3 hours... but here it is..

I found a fix... through trial and error.

InProc and StateServer in sessionstate both had the same results until I added "cookieless=true"

<sessionState mode="StateServer" cookieless="true" />

This causes the session state to be consistent in both Chrome and in IE (where the problems was) and my session ID no longer changes between page refreshes. I was unable to determine WHY this happens, but it is fixed nonetheless.. Thanks Mike and antinescience for your help!

Adam Wood
  • 289
  • 2
  • 4
  • 13
  • Why not just use `FormsAuthentication.RedirectFromLoginPage(userName.ToUpper(), true);` and forget the session... not really the best way to handle authentication. – MikeSmithDev Mar 24 '13 at 20:22
  • I don't do that type of redirect because the login "form" is actually in an update panel that pops up in a pseudo-modal box (using jQuery) and it then posts back returning value for "invalid login" or just redirect to itself. The reason for doing it this way is business related, not because it's the best way. – Adam Wood Mar 24 '13 at 23:02
  • You can still set the cookie in a similar way `FormsAuthentication.SetAuthCookie(userName.ToUpper(), true);` and then do your redirect.. the point isn't how you set an authentication cookie, its about using Session for authentication management. – MikeSmithDev Mar 24 '13 at 23:05
  • It is a preference to keep the username in the session... But, at this point it appears the issue is no longer with authentication at all (well, never was in OP, but with redirect), it appears that the problem is that using IE causes the server to think it needs a new session on any page update, even by simply clicking refresh. – Adam Wood Mar 24 '13 at 23:40
  • You can get the username from the cookie... ASP.NET also allows for cookieless authentication. Your intent really isn't clear... Sessions are good for some things... bad for others, like auth. – MikeSmithDev Mar 24 '13 at 23:41
  • I appreciate the help Mike... And I just may switch to that method... I think I'm more concerned at this point that sessions are being created for every refresh of the page... I'm wondering what IIS services are going to look like when 100 people are hitting 10 page in a minute on this... IIS thinking each is a "new" hit. And wondering why IE causes this but Chrome doesn't – Adam Wood Mar 24 '13 at 23:44
  • Glad you cleared it up! – antinescience Mar 25 '13 at 01:47
  • http://www.hanselman.com/blog/FormsAuthenticationOnASPNETSitesWithTheGoogleChromeBrowserOnIOS.aspx might provide a tiny bit of insert for you – Daniel Powell Mar 25 '13 at 02:10

5 Answers5

4

InProc and StateServer in sessionstate both had the same results until I added "cookieless=true"

This causes the session state to be consistent in both Chrome and in IE (where the problems was) and my session ID no longer changes between page refreshes. I was unable to determine WHY this happens, but it is fixed nonetheless.. Thanks Mike and antinescience for your help!

Adam Wood
  • 289
  • 2
  • 4
  • 13
2

There are some other reports that indicate that IE's caching mechanism (which is widely regarded as, well, not great) may be to blame here. Can you try appending the following to your page:

// Stop Caching in IE
Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache);

// Stop Caching in Firefox
Response.Cache.SetNoStore();

...and see if that has any effect? The other alternative is you could do:

int randomNumber = new Random().Next(1, 1000);
Response.Redirect("/?nocache=" + randomNumber);

...just for testing. Heck, you could slap the date as numeric in to test as well.

antinescience
  • 2,339
  • 23
  • 31
1

i had the same problem for couple of days now and finally i knew the reason why the session was changed each refresh, first after using the Response.Redirect( URL ,false) method i realized that i was entering the URL as AbspoluteURI as "http:// ServerIP/File/Page.aspx" , i used the AbsolutePath method instead as "~/File/Page.aspx", and my problem was solved!! the IE thinks that the server was changed when you write AbsoluteURL instead of AbsolutePath, i wish this could help

Mumin Asaad
  • 180
  • 9
0

I had the same problem with a webpage which was hosted inside an IFrame. Troubleshooting showed that the ASP.NET Session cookie was lost along the way, and it only happened when using Internet Explorer. When I opened up my webpage in a separate tab in IE everything worked fine.

The problem was caused by security in Internet Explorer. It will not persist cookies unless there is a P3P HTTP header. You can see the blocked URLs by going to IE->View->Webpage privacy report..., and there choose to show "Restricted websites".

I solved the problem by adding a dummy P3P header with every request. The header looks like this;

P3P:"Bogus P3P header because Internet Explorer requires one"

This is the same approach as facebook.com uses. Their p3p header looks like this;

p3p:CP="Facebook does not have a P3P policy. Learn why here: http://(...)/p3p"

See also Cookie blocked/not saved in IFRAME in Internet Explorer

Community
  • 1
  • 1
Frode Lillerud
  • 7,324
  • 17
  • 58
  • 69
0

I had this issue too, this SO response solved my problem. If your hostname has underscores (which seems to be invalid), IE seems to drop the session (!).

Amessihel
  • 5,891
  • 3
  • 16
  • 40