I have an ASP.net application that uses a cookie to store the user selected language.
Everything works fine except when I'm on localhost.
Replacing localhost by 127.0.0.1 makes it work again... why?
I saw intended restrictions to file:// but I can't actually find any reference to intended restriction to localhost.
What I can't really understand is why the ASP.net Session (ASP.NET_SessionId) and ASP.net Forms Authentication Cookies (.FSAUTHSSO) are correctly set for the localhost domain but my cookies aren't... why?!
I already googled a lot and nothing works:
Setting the Chrome command line flag --enable-file-cookies [DOES NOT
WORK]
Setting the cookie to HttpOnly [DOESN'T MATTER]
Changing Expiration to Session or to a Date... [DOESN'T MATTER]
Changing the Cookie Path to Root (/) or to anything else [DOESN'T MATTER]
So what does matter? :)
And why can the ASP.net cookies be set and mine don't? What's the difference?
Last thing just to mention that this also happens on IE but works fine on FF.
Thanks!
Alex
Cookies are designed for second level and down. First level domains will not work. Instead you should use the address http://127.0.0.1 (as you mentioned) or you could edit your hosts file to map a different URL with a TLD to the address 127.0.0.1 such as:
yoursite.tld 127.0.0.1
Just researched this further; found this answer: Cookies on localhost with explicit domain
please try to put cookie.Domain = null on localhost and use the domain name otherwise.
This was driving me nuts for hours! Then I realized:
I recently used HTTPS://localhost and set a cookie with the same name.
That was the reason HTTP://localhost was unable to set the cookie
So I went to https, cleared the cookies in the "application" tab in devtools and it started working with http again
I fixed my problem by going to chrome://flags/ then search for cookies. Set the following 3 flags to disabled...
SameSite by default cookies
Enable removing SameSite=None cookies
Cookies without SameSite must be secure
Good news. Setting cookies on localhost is now possible on Chrome starting Canary build:
https://code.google.com/p/chromium/issues/detail?id=551906
I just had the same issue in Chrome. I had cookie.Secure = true. Getting rid of that for localhost fixed the issue for me.
(Had the exact same issue, FWIW: worked in FF, not IE or Chrome)
I know this might be silly but it just happened to me where I took over an asp.net mvc application where I could not get them to work locally. Finally, another developer pointed to an entry in the web.config that had been added recently.
<httpCookies httpOnlyCookies="true" requireSSL="true" />
Setting the requireSSL to "false" locally. Remember to apply the transformations through the environments.
I hope this helps.
There is an issue on Chromium open since 2011, that if you are explicitly setting the domain as 'localhost', you should set it as false to it work or use set the domain as 127.0.0.1.
I had an issue on chrome where a cookie with an expiration of 2 weeks in the future was not being set - this happened to be the auth cookie (.AspNet.ApplicationCookie) so I was continually being redirected back to the login page. This issue did not occur in other browsers I tried.
I ended up experimenting with custom cookies to determine that chrome thought the current date was earlier than it actually was - so for example I put in a cookie that expired in 1 year today (2-Apr-2017) and actually chrome set this cookie to expire 1-Jan-2017! This would then explain why a cookie with a 2 week expiry was already considered expired as chrome was lopping off 3 mths of the actual expiry and thus considered it already expired.
Chrome reboot didnt fix this - I rebooted the PC at this stage and this 'fixed' the bug. Also I should note this only occurred for localhost - seemingly every other site was ok.
For my situation, I was running an asp.net core razor pages app using iisexpress (localhost:####) and I ran into this issue with Chrome. My fix was to make sure the iisSettings in the Properties\launchSettings.json has number other than 0 for sslPort (44344). With the sslPort set to 0, iisexpress will not run will ssl. Changing it 44344 then runs the app using ssl in iisexpress. Alternative, going the project properties in Visual Studio and the Debug tab to Enable SSL will do this same change to launchsettings.json For example
"iisSettings": {
"windowsAuthentication": false,
"anonymousAuthentication": true,
"iisExpress": {
"applicationUrl": "http://localhost:29025/",
"sslPort": 44344
}
},
To Run this in your local machine with Chrome browser >=79 please follow below steps.
I fixed my problem by going to chrome://flags/ then search for cookies. Set the following 3 flags to disabled...
SameSite by default cookies
Enable removing SameSite=None cookies
Cookies without SameSite must be secure
Go to - chrome://flags
Just disable this 3 option. Must it works.
Stuck on this problem for hours and the problem was that the cookie had the wrong path. So everyone check what path the cookie is set on!
Related
I've been using Postman in my app development for some time and never had any issues. I typically use it with Google Chrome while I debug my ASP.NET API code.
About a month or so ago, I started having problems where Postman doesn't seem to send the cookie my site issued.
Through Fiddler, I inspect the call I'm making to my API and see that Postman is NOT sending the cookie issued by my API app. It's sending other cookies but not the one it is supposed to send -- see below:
Under "Cookies", I do see the cookie I issue i.e. .AspNetCore.mysite_cookie -- see below:
Any idea why this might be happening?
P.S. I think this issue started after I made some changes to my code to name my cookie. My API app uses social authentication and I decided to name both cookies i.e. the one I receive from Facebook/Google/LinkedIn once the user is authenticated and the one I issue to authenticated users. I call the cookie I get from social sites social_auth_cookie and the one I issue is named mysite_cookie. I think this has something to do with this issue I'm having.
The cookie in question cannot legally be sent over an HTTP connection because its secure attribute is set.
For some reason, mysite_cookie has its secure attribute set differently from social_auth_cookie, either because you are setting it in code...
var cookie = new HttpCookie("mysite_cookie", cookieValue);
cookie.Secure = true;
...or because the service is configured to automatically set it, e.g. with something like this in web.config:
<httpCookies httpOnlyCookies="true" requireSSL="true"/>
The flag could also potentially set by a network device (e.g. an SSL offloading appliance) in a production environment. But that's not very likely in your dev environment.
I suggest you try to same code base but over an https connection. If you are working on code that affects authentication mechanisms, you really really ought to set up your development environment with SSL anyway, or else you are going to miss a lot of bugs, and you won't be able to perform any meaningful pen testing or app scanning for potential threats.
You don't need to worry about cookies if you have them on your browser.
You can use your browser cookies by installing Postman Interceptor extension (left side of "In Sync" button).
I have been running into this issue recently with ASP.NET core 2.0. ASP.NET Core 1.1 however seems to be working just fine and the cookies are getting set in Postman
From what you have describe it seems like Postman is not picking up the cookie you want, because it doesn't recognize the name of the cookie or it is still pointing to use the old cookie.
Things you can try:
Undo all the name change and see if it works( just to get to the root of issue)
Rename one cookie and see if it still works, then proceed with other.
I hope by debugging in this way it will take you to the root cause of the issue.
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 (!).
I've run into a problem where login on my site is not working consistently in IE8. It works fine in Firefox/Chrome/Safari but not IE8.
On first login everything is fine. After logging out and trying to log back in it usually fails for a while. It will end up redirecting to the login page against after authentication.
So the authentication is successful, it returns true, but it seems IE8 is not accepting the new value for the session id which we set by returning:
Set-Cookie SESSIONID=........; Path=/
in the response header. But obviously this works with a clear cache and I can get in fine. But after its already there it fails to reset, so after authenticating and attempting to go to a new page it sees this is an old session id being sent from the browser and redirects to the login page.
I haven't found anything here or elsewhere that really solves this (besides clearing the cache). Most references to IE8 cookie problems are language/framework specific and don't answer this problem.
Is there something special I might need to do with the set-cookie to make this work?
UPDATE:
I've set IE8 to prompt before accepting any cookie. When the login works fine it prompts as expected. When it does not work there isn't even a prompt to except the cookie..
UPDATE 2:
I should have mentioned that the cookie is expected to be set after an ajax call:
$.get(authenticate_url, ....)
The url it requests a response from returns the header that sets the session id, then in the callback function the user is redirected to the main page -- assuming login is successful.
Is it a first party cookie or a 3rd party cookie. If the latter, ensure you're sending a P3P header.
Are you setting the HTTPOnly attribute?
Are you sure that the domain for the cookie is always the same? E.g. if you set the cookie when visiting "example.com" and tried to change it from "www.example.com" then you'll encounter problems.
I've hit similar symptoms when I have cookies set for both www.example.com and example.com. If there's no domain explicitly set, then session cookies get set for both.
However, higher-level domain cookies take precedence over the lower domian. So, if www.example.com tries to set a cookie, but example.com already has, then the example.com cookie stays in place and continues to apply for www.example.com.
There are two ways to approach this problem. One is not to allow access both with and without the www subdomain. Redirect one to the other. The second is to explicitly set the cookie domain, so that there aren't two versions lying around.
Of course, that might not actually be your issue. Experiment and find out :)
I have an ASP.NET 2.0 application. The login page redirects twice when the login is successful. This works OK on all test environment and production servers except one. We can see with Fiddler that the login redirects to the second page and it redirects to the third. When getting to the third page the authentication cookie is lost, and the page redirects back to the login.
As mentioned this happens only on one production server with IE7.
It works fine if we try IE7 from the server itself. It only fails from other client machines.
It works perfectly well if I just try the same from FireFox. I can see clearly of fiddler, that in this case the cookie is not lost.
Any ideas?
This is a longshot, but does the servername have an underscore in it? A while back, there was an IE bug where it couldn't save cookies from a servername/URL that had an underscore in it, so if I accessed the server by http://server_name, I couldn't save a cookie, but accessing it via http://intranetdnsalias would work just fine.
Are you setting a cookie with a domain name set? When browsing, does your URL contain the domain name?
"localhost" cookies don't really work like domain-set cookies and can often disappear.
HttpCookie contains the domain parameter to set.
This sounds like an IIS config problem. Have you tried to recreate the website on that server with defaults?
The dates are consistant? e.g. 10.09.2008 == 09.10.2008 if the locale is wrong. So if you set a specific expiry it might be interpreting it as en-US but you need en-NZ or something.
Or you could be setting it as a UTC date but the ie computer is UTC+8 so it appears to expire quickly?
Getting sporadic errors from users of a CMS; Ajax requests sometimes result in a "501 Method not implemented" response from the server. Not all the time; usually works.
Application has been stable for months. Users seem to be getting it with Firefox 3. I've seen a couple references via Google to such problems being related to having "charset=UTF-8" in the Content-type header, but these may be spurious
Has anyone seen this error or have any ideas about what the cause could be?
Thanks
Ian
You may want to check the logs of the server to see what's causing the issue. For example, it might be that these requests are garbled, say, because of a flaw in the HTTP 1.1 persistent connection implementation.
Try this
Try clearing your cookies and your cache
Type about:config into the URL bar, list of configuration settings for Firefox
Locate the setting for 'network.automatic-ntlm-auth.trusted-uris'
Set the value of names of the servers to use NTLM with.
Locate the setting for 'network.negotiate-auth.trusted-uris'
Set the value of names of the servers to use NTLM with.
network.automatic-ntlm-auth.allow-proxies = True
Restart Firefox - Test URL to application
The problem occurs as your app is not running on the same domain as your service. You need to configure your Server to accept those calls by adding the 'Access-Control-Allow-Origin' Header.