I have an asp.net site. Its a mixture of web forms and MVC2.
I have this on 2 different servers which I get to via different urls.
On one server authentication works fine via all browsers (IE 8, FF 3.6, Chrome)
On the other IE 8 fails, it doesn't send back the cookie on the request to the page after authenticating.
Using Fiddler I have seen that both sites attempt to set the cookie, in the response from the login page.
Response Header I see from both servers
Set-Cookie: DemandLaunch=CCA4...E79C2D1; path=/; HttpOnly
Both sites are in the internet zone of IE.
I'm at a loose for what to check now.
I also have a page that sets a cookie via c# code and that cookie fails in IE as well.
The IE issue is not on a single computer either. I see this failure on 4 different computers Internet Explorer.
My urls which I should have included were:
beta.[site].com - works
beta_[company].[site].com - fails
Check the name of the server. It shouldn't have an Underscore in its name.
If that doesn't help, you should try these out...
Link
http://aspalliance.com/1182
Related
I have a legacy web application. The app needs to be opened in IE while the user opens it from Edge Chromium. I've added the URL to the EM site list XML on a NAS share. This works great for other legacy applications we have.
However, this application uses a HTTP POST request.
When a user navigates in Edge to the web application, it loads fine in a new IE11 screen.
But when you use the search, it opens in a new Window and it seems the parameters from the HTTP POST request are not included. This results in a null request.
Is there any setup needed to include the HTTP post request in IE mode? I can't find this anywhere in the MS documentation.
We've replaced the post request with a get request and solved the issue this way
We had the same symptoms. I did not verify that the http method was changed from POST to GET, but the form variables from a POST operation were not being transmitted to the next page.
We were able to get this working by adding the source page (the one with the form variables in it) to the Enterprise Mode Site List in Edge.
In Edge, paste the following into the address bar (without the quotes): "edge://compat/SiteListManager"
I checked the box to Allow Redirects and also used IE5 Document mode as the Compat Mode because that is what was indicated by f12 tools when running the same page in real IE 11.
See also https://learn.microsoft.com/en-us/deployedge/edge-ie-mode-site-list-manager
And https://learn.microsoft.com/en-us/deployedge/edge-ie-mode-faq
Chrome 86 (and prior), Edge, Curl, and IE all are able to do cross-origin Windows Authentication against my IIS 10 ASP.NET service on Windows 2019 machine without any problem.
But Chrome 87 fails with "Access to XMLHttpRequest at 'https://[REDACTED]' from origin 'http://[DIFFERENT]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested"
Weirdly - Chrome 87 works with the identical ASP.NET service running in IIS 7.5 on a Windows 2008 machine (don't ask) that is configured identically.
UPDATE: Note - I realized [2020-12-04] that the "working" system happened to be on a different domain that was already added to my "Sites that can always use cookies" list. So the "fix" was staring me in the face right from the start... ;)
Using curl - I can't see any difference between the IIS responses for Windows Authentication.
If I hack my ASP.NET and have it include a echoed Access-Control-Allow-Origin 'http://[DIFFERENT]' to all requests instead of the main one - then Chrome 87 barks a 401 - not authorized - instead of continuing with the Windows Authentication back and forth. Curl and the other browsers are just fine with the additional headers.
Invoking the website directly (without cross-origin) works just fine.
Anyone have a clue what Chrome 87 is doing different? The Dev Tools only shows the "last" request in the chain - so I don't know what is happening prior to the failure.
UPDATE: [2020-12-02]
Apparently the Chromium Team is claiming it is working the way it needs to... But it seems weirdly broken to me.
https://bugs.chromium.org/p/chromium/issues/detail?id=1154281
"This is now expected behavior - blocking third party cookies now acts like setting crendials:omit on third party requests. We'll see how many reports we get about this, but the previous behavior was buggy, since truly uncredentialed requests and those that had provided HTTP auth credentials, but no cookies, would share sockets."
We are seeing the same in our environment, Chrome 87 is now applying the cookie rules to Kerberos and NTLM authentication (clearly a bug). This is affecting not just XHR but any resource loaded from another site (images, iframes, etc).
We have "Block third-party cookies" set and have found that adding affected sites and domains to the "Sites that can always use cookies" list in Chrome has restored authentication; and is an acceptable workaround for us since we manage Chrome via Group Policy and can push out an updated list of sites easily.
2020-12-02:
As of today MS Edge 87 exhibits the same behaviour.
I have two Spring Web applications that work together. I'm running the first application from the IDE on localhost, while the second one is running in docker on app.127.0.0.1.nip.io.
The two applications interact indirectly through the users browser by redirecting and POSTing between the two apps. This is slightly similar to how an SP and an IdP work together in SAML2.
In my case, the first application on localhost is sending a 302 to the second application. After doing some work, the second application sends an HTML page with a form an JS code to autosubmit it, back to my first application on localhost. The HTML looks similar to this:
<form method=POST action="http://localhost:8080/some/path">
...
</form>
My first application is using Spring Session with a session cookie, and this works just fine. However, when the second application makes the browser POST the form, the browser does not send the session cookie with the POST request.
When both applications are running in docker under .127.0.0.1.nip.io, the cookie is sent.
I've tried to find any hint if this behaviour is expected, and what headers or other bits the applications could use to influence this.
At this point, this is mostly an annoyance while debugging, but I'm concerned that once the two applications will run on different FQDNs and/or different domains, the browsers will also block the cookie being sent.
I've tested this with current versions of Chrome and Firefox.
The problem is the new(ish) SameSite cookie policy that covers exactly this case: another application is POSTing to a host via HTTP. The default now is SameSite: lax, which does not allow sending the first-party cookie values on this request.
The solution is to allow the session cookie to be sent by specifying SameSite: none. Be aware however that this might create security vulnerabilities. For my application, this is not an issue, so I can allow the cookie to always be sent, and especially when I run my application in the debugger.
For the production deployment, I will be able to tighten this, since both applications will run under the same domain (a.example.com and b.example.com), and both will use TLS, so I can set the session cookie to SameSite: lax.
Here's a decent explanation: https://web.dev/samesite-cookies-explained/
Ok, so I get the rule that browsers should not confuse history store and web cache: Clicking back should not send a request to the server. I also get that browsers manufacturers have the poetic licence to break this rule.
What I don't get is the following (please stay with me here)...
OK: Browsing our web site in HTTP, the history buttons did not send requests to server. Great! Behaviour as expected.
NOK: Browsing history on the same site in HTTPS mode, Chrome faired well but IE9/10 and FF did not. They would send the request for the HTML page to the server and then correctly use the store for the static files. Why the difference?
So after a little head scratching and testing, I found that the presence of the Pragma:no-cache header in the responses we were sending was responsible for this behaviour. After removing the header, that should never have been there in the first place, IE and FF faired well when using history buttons in HTTPS - no more sent requests.
Now, how can the presence of a header which should be ignored by modern browsers and only used in requests, be causing this strange issue in browser history navigation?
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?