I am writing a web app using SignalR cross domain communication. I am using the latest version of SignalR, 1.0.1. Following is the code in the jQuery's document ready event:
var connection = $.hubConnection(url);
var proxy = connection.createHubProxy(hubName);
connection.start().done(function () {
proxy.invoke('serverMethod');
});
I tried running the application on Opera, Firefox, Chrome and IE 10. My OS is Windows 7. It works well on IE 10 and doesn't work on other browsers. I changed mode of IE using developer tools to IE 9, and it stopped working. The same code works on all browsers if I use SignalR version 0.5.3.
In developer tools of the browser, I found the following HTTP status code in response of negotiation request: "HTTP/1.1 403 Forbidden".
Am I missing anything here? What is the reason because of which it is breaking on browsers other than IE 10?
Ensure that in your MapHubs call that you enable cross domain.
RouteTable.Routes.MapHubs(new HubConfiguration() { EnableCrossDomain = true });
When testing cross domain locally IE10 has an interesting feature that treats any localhost port as not being cross domain.
Related
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'm using IIS 10 server as a gateway for Node.js server.
When client calls download files such as zip file, IIS server download Node.js server internally with HTTP protocol, and then it pass to client with HTTPS.
But in Chrome web browser, It shows error
net::ERR_HTTP_1_1_REQUIRED with status 200, and when I try to download again it works well until I clear the caches.
In Firefox, it returns status 200 too, but nothing's happen.
In Microsoft Edge and IE11 works well too.
I've set enough timeout and buffer size in IIS.
May Chrome and Firefox go wrong at HTTPS - HTTP connection or something else?
There may be some extensions in your Firefox and Chrome that can cause this error. This error means a browser extension blocked the request. The most common culprit is an ad blocker like AdBlock Plus. In short your requests to server have been blocked by an extension. so you can try to disable these extensions and try again.
It seems that the .NET Core team found a related issue and provided a workaround.
Perhaps the same can be applied with other frameworks.
https://github.com/dotnet/aspnetcore/issues/4398
Apparently, when doing an ajax request from a browser, it will sometimes send an OPTIONS request before the real request with a 204 status code which causes the problem.
For me, it seems to have solved my problem to return the file with a response content-type of "text/plain" instead of "application/octet-stream"
I'm not really sure why it works, it just does.
I'm making a PWA and is hosted on Firebase. I can see my page in Chrome, IE and other browsers. But I have problems with Safari and Opera. I have SLL certificade and TLS 1.2 (both from firebase) with nginx as server.
I tested my page on browsers and I get errors like:
"Safari can't open the page -url- besause safari can't establish a
secure connection to the server -url-"
"Can't establish
communication with protocol SSL/ TLS"
"Fatal Error (70) from
server " (Opera/Debian)
And in htbridge I got:
*HTTPS protocol, failed CSP status
*Many "The header was not sent by the server."
*I don't have have a Certification Authority Authorization (CAA) record.
*No support of TLSv1.3
*Server doesn't provide HPKP
So, I guess is something about security. But I don't know why it can be the main problem.
I tried to correct some stuff some commands on the server (nginx) but I don't know where is that or what I need to do. I am new to these things and I need someone to guide me a little at this point.
What should I do or is something I don't know?
Opera is exactly following the footsteps of Chrome, so if it works on Chrome shouldn't be problem on Opera, i would say just uninstall the Opera and re-install it. Also, check what versions you have got? to get he maximum of both browsers you need latest versions. Also, there are certain restrictions on Safari regarding PWA and service worker. Although, both Safari and MS Edge working on it and all the main browsers are getting into the same page on the issue of PWA (i.e. Service worker, Cache Api and IndexedDB).
It turns out that I was testing on obsolete versions of Safari and Opera for Windows. For some reason it did'nt work on a specific iphone and hence my confusion. Thank you for your help!
We implemented SignalR 2.0 hub with CORS enabled. Javascript clients on Firefox and Chrome are running fine. IE 10 gets error 403.
Any help will be appreciated.
Thank you and regards.
While IE 10 (but not IE ≤9) should support CORS, if you find yourself needing to use JSONP you can enable it when you call MapSignalR.
Enabling JSONP allows your SignalR app to be accessed from any origin while sending cookies/credentials. With CORS, you can limit which origins are able to access your SignalR app, whether or not cookies/credentials should be sent with cross-origin requests and more. Since JSONP cannot be configured to match the more fine-grained security policies made possible by CORS, JSONP must be enabled separately:
app.MapSignalR(new HubConfiguration
{
// You can enable JSONP by uncommenting line below.
// JSONP requests are insecure but some older browsers (and some
// versions of IE) require JSONP to work cross domain
EnableJSONP = true
});
If you are using a PersistentConnection replace HubConfiguration with ConnectionConfiguration.
You can learn more about establishing a cross-domain SignalR connection here.
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