I am a bit baffled here; using IE7, ASP.NET 2.0 and Cassini (the VS built-in web server; although the same thing seems to be true for "real" applications deployed in IIS) I am looking for the session-id-cookie.
My test page shows a session id (by printing out Session.SessionId) and Response.Cookies.Keys contains ASP.NET_SessionId. So far so good.
But I cannot find the cookie in IEs cookie-store! Nor does "remove all cookies" reset the session (as it does in FF)... So where - I am tempted to write that four letter word - does IE store that bloody cookie? Or am I missing something? By the way there is no hidden field with a session id either, as far as I can see.
If I check in FF there is a cookie called ASP.NET_SessionId as I would expect. And as mentioned above deleting that cookie does start a new session; as I would expect.
Can anybody imagine what is happening here?
The ASP.NET session cookie is non-persistent, so it doesn't get saved to your hard-drive. It gets transmitted back and forth while you're using the application, but it gets discarded when you close the broswer.
From MSDN:
Note
When you run this code, you might see
a cookie named ASP.NET_SessionId. That
is a cookie that ASP.NET uses to store
a unique identifier for your session.
The session cookie is not persisted on
your hard disk. For more about session
cookies, see the "Cookies and Session
State" later in this topic.
Related
Everyone claims a domain must have two dots in order for a cookie to be stored, but that cannot be true, because Chrome is storing the cooking named "__RequestVerificationToken" received through the Set-Cookie header from ASP.NET; however, it refuses to store other cookies. I literally am sending a virtually identical cookie with a virtually identical Set-Cookie header, and yet Chrome is refusing to store it. The path is "/", just like the other one. No domain is set. The only difference is the name. Is Chrome giving "__RequestVerificationToken" some kind of special treatment?
Looks like Chrome will save "session" cookies for "localhost", but not "permanent" cookies. No idea why it makes the exception for "session" cookies, but the "permanent" ones aren't stored because cookies are only supposed to be stored for 2nd level domains (domains with at least 2 dots, which localhost is not).
"permanent" cookies are cookies that DO set an expiration date, which is a bit counter-intuitive, but they're "permanent" in the sense that they survive across browser restarts unlike "session" cookies which are supposed to be deleted when the browser closes. In reality, they're all relatively permanent, because Chrome/Firefox typically don't delete the session cookies when the browser closes, thanks to features like "continue where I left off" and "restore my tabs when the browser restarts".
Another takeaway is that we may as well not set an expiration on any kind of session or auth cookie at all, because it offers the following advantages: 1. it works on localhost, 2. it more secure in that they stand a chance of being deleted when the browser closes, and 3. they persist across browser sessions anyway if the user has the browser configured to do so, so setting a long timeout isn't necessary. Setting an expiration on the cookie also doesn't do you any good anyway, because it's just another value to sync with the server-side session, the value isn't sent to the server with the cookie anyway, so it's useless, and utimately the server-side expiration for the token (stored in session or database) is authoritative anyway. So just don't set an expiration on your session or auth-related cookies.
I have an ASP.NET MVC application that is exhibiting some strange behavior...
Each page request gives me a new Session ID, I have tried everything that I can think of and its still not working.
The session is not empty, I am writing data to it on session start.
I have read the other questions on here and have checked:
1. All requests and coming from and going to the same domain.
2. The session is not empty.
3. The session is not being abandoned anywhere in the code.
I have used fiddler to confirm that the server is giving a new session ID on every request.
I have also checked the value of Session.IsNewSession and this is TRUE.
I must be missing something - if you have any idea what it might be I would really appreciate the help!
Fiddler output:
You are sending a session cookie that is marked "secure", but are making requests through HTTP (insecure). Either access your site through https, or change your session cookie to be non-secure.
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!
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!
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.
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
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
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 (!).
H
Regarding this URL
http://www.codeproject.com/KB/aspnet/FlashUpload.aspx
User.Identity as System.Web.Security.FormsIdentity is always null, because the Identity is GenericIdentity, I assumed it will be as in the tutorial FormsIdentity, what is chances.
Thanks
Rather than Casting to FormsAuthentication, Simply get the cookie .ASPXAUTH (or the name specified in the web.config) and send it to flash and then let flash put it as a POST variable while uploading, then Read Request.Forms[POSTVariable] and create the FormsAuthenticationTickt as illustrated by the tutorial in the question.
This is the problem with Flash, and it has nothing to do with your server side code and here is why.
When Flash makes web service calls, http service calls to the same domain it came from, it regains cookies and in turn the each calls are made within your session (ASP.NET Session), but when you upload something flash does not send cookie (A bug reported to adobe with no response till date).
This is the reason FormsIdentity is null, because ASP.NET Server needs cookie in order to assign FormsIdentity to properly authenticated user request.
Thats why when you upload, you will never get the session, the work around this is, we pass a custom authentication hash in querystring that we can validate on the server side.
I have a web app that is being hit by facebook. The login page retrieves the keys that I need and sets some session variables. When the server then redirects the user to the next page, the session information is lost. I’m running the IIS engine on vista ultimate at the moment, the app pools don’t matter because I’m using a state service and I’m still losing the session state. I’ve tried both the overloaded method of the response.redirect function and also adding a header to the page to force the redirect and none of this seems to work. Does anyone have any ideas of what I’m missing?
I’ve tried both of these:
Response.Headers.Add("refresh", "3;url=Dashboard.aspx")
And
Response.Redirect("Dashboard.aspx", False)
[EDIT]
So i just did a little experiment and well it turns out that when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
[EDIT]
So I found an article on this and after addin gthe header the problem was solved (for now)
http://support.microsoft.com/kb/323752
Response.AddHeader("P3P: CP", "CAO PSA OUR")
when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
If you're in an iframe, any cookies you set are “third-party cookies”. Third-party cookies may be subject to more stringent conditions than the normal “first-party” cookies you are setting when the user is directly on your site. This can be due to different browser default cookie handling or because the user has deliberately configured it like that. (And for good reason: many third-parties are unpleasant privacy-invading advertisers.)
In particular, in IE6+ with the default settings, you cannot set a third-party cookie unless you write a P3P policy promising that you will be a good boy and not flog your users' data to the nearest identify thief.
(In practice of course P3P is a dead loss, since there's nothing stopping the site owner from just lying. Another worthless complication that provides no actual security. Yay.)
I'd try running Fiddler and see if your session cookie is being sent properly with the response when interacting with your app via Facebook.
The session depends also on cookie support by the client. When you say the app "is being hit by facebook" are you sure that by what ever means they are "hitting" you they are supporting cookies?
Response.Redirect and refresh don't carry session. Server.Transfer() can but loses the ability to transfer to other servers/sites.