No 'Access-Control-Allow-Origin' header - Same Domain? - javascript

Today I attempted to browse a new feature recently deployed to our testing environment (NOT LOCAL). After navigating to the new feature I was met with a blank page. Confused, I checked Chrome's console and found an error:
XMLHttpRequest cannot load https://test.mytestsite.com/SomeApplication/api/SomeController/SomeMethod/8?Id=523283&SecondId=1612w3426653.
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://test.mytestsite.com' is therefore not allowed access.
This code makes an ajax call to a WebAPI (on the same domain) to retrieve some information on document.Ready. I understand the error and I'm familiar with it's typical cause. However, this call is being made from within the same domain AND it works for the other developers on my team.
Symptoms:
- Does not work for IE or Chrome/Incognito
- Does work for FireFox
- Works on all browsers for at least 4 other developers on the same domain that I reside on. (Indicating to me that this is an environmental issue)
Possible causes:
- I was doing some CORS research several weeks ago and perhaps I configured some Windows 7 setting to cause this to happen?
Google is saturated with the standard CORS issues, so I'm asking here and hopefully someone can help.

The issue at hand was due to inconsistencies between environments.
In our production environment SSL is enforced with a redirect in IIS, while in our testing environment it is not. I was navigating to the site via a bookmark using http. Updating the bookmark, as #epascarello suggested, fixed the problem.

Related

Autodesk Forge Cross-Origin Request Blocked Error

We have web applications where we use Autodesk Forge viewer. These were working as usual until yesterday. We didn't make any changes for months for some of them and now out of nowhere, we are receiving Cross-Origin errors.
I have checked 3 of our web application with Forge, none of them are working! Firefox and Chrome give these kind of errors:
Access to XMLHttpRequest at 'https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/res/locales/en/allstrings.json' from origin 'WEBSITE NAME' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'http://localhost:3000' that is not equal to the supplied origin.
Access to XMLHttpRequest at 'https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/lmvworker.min.js' from origin 'WEBSITE NAME' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'http://localhost:3000' that is not equal to the supplied origin.
and more png loading problems with errors above.
I don't know if it is because of deployment platform heroku. I need help on this since I have no idea what has changed. On the one of the platforms, there were made no changes since last year but it stopped working also.
I am using this url to load the viewer:
https://developer.api.autodesk.com/modelderivative/v2/viewers/style.min.css?v=v7.*
https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/viewer3D.min.js
I need to mention that at localhost, Forge Viewer loads the model without CORS Error and works fine.
Thanks for the help.
Update:
According to #Can777, this issue was resolved by clearing browser history.
The problem is solved by deleting the browser histories from all
browsers (Firefox nearly didn't have any history actually, since we
only use chrome).
=============
I'm sorry to hear this issue is bothering you. We have reported this issue to our engineering team to have a look. We will keep you updated once we got responses from them. We apologize for any problem that had caused to you.

Google App Script postMessage does not match recipient window's origin

I have a Google App Script deployed as a Web application.
It was working normally, until this evening I discovered it would not load in Firefox or Chrome.
In Firefox I am getting this message;
Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘https://n-...-0lu-script.googleusercontent.com’) does not match the recipient window’s origin (‘https://script.google.com’).
Removed part of URL
The app is deployed: (Executing as myself, and is Accessible for anyone, even anonymous).
I thought the issue might be with LastPass as mentioned here, but I have disabled LastPass in both browsers and the issue persists.
I'm not sure if this is a bug or a feature, but web apps starting in Chrome 60 may need to be set to XFameOptionsMode.ALLOWALL. I have a long running web app that just broke. Setting this worked.
XFrame Options Docs

XMLHttpRequest cannot load cloud 9 io

I am getting an occasional 'XMLHttpRequest cannot load' error while using the cloud 9 cloud hosted development environment.
The full error is 'XMLHttpRequest cannot load https://c9.io/_user_content/authorize?redirect=http%3A%2F%2FprojName-username.c9.io%2Fusers%2Fanswers. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://projName-username.c9.io' is therefore not allowed access.'
The error is inconsistent. It has shown up (and not shown up) on various pages and often my page will work if I just reload it and try the exact same thing again. Is anyone else running into this error on cloud 9 or perhaps my internet connection is just unreliable? I am using the MEAN stack on a micro instance of cloud 9 with 1 GB ram and 10GB storage.
This is a temporary bug that arose as a result of changing the app preview URL from c9.io to c9users.io. The change was made in order to protect users and increase security. A fix will be out for this soon.
In the meantime you can set your application to public (your code will still be private and undiscoverable) by clicking "Share" in the top right and then checking the box next to your application URL.
Update: This bug has now been fixed. Any further issues similar to this should be submitted at https://community.c9.io so they can be addressed properly.

Chrome blocking iframe requests as cross-origin request even when origins are the same

This one has me stumped.
I have a web app that has a file upload/download area. Files are downloaded in the background via a temporary iFrame element. This is a single-paged AJAX application and the UI is written in Javascript, jQuery and uses the jQuery.FileDownloader.js to manage the iFrame. The application runs over HTTPS and the site and download URL are on the same exact domain. The back-end is a RESTful application. This has worked great for months. Until today.
All of a sudden, when attempting to download a file in Chrome, the browser reports an error of "Blocked a frame with origin https://example.com from accessing a cross-origin frame."
The problem is that the origin of the main site and that of the iframe are the exact same domain. I have ensured that the domains are the same as well as the protocol. Chrome is the only browser that throws up the cross-origin error. IE, Firefox, Opera, Safari... all work as expected. It's only in Chrome and it's only as of today. To make things worse, no updates were made to the browser. It truly is spontaneous. I've also ruled out plugins as the cause by running in Incognito mode, where none are allowed to run by my settings, as well as disabling my anti-virus software. This problem is being exhibited on other computers, in other locations (not on our LAN or subnet), all running Chrome.
And, again, both domains of the parent frame and the embedded iframe are identical. This only happens against the production server which runs over HTTPS. Other non-HTTPS sites (e.g. our dev environment, localhost) don't have the problem. Our SSL is valid. Since this is a single-paged AJAX application, we're trying to avoid popping up another window for the download.
Hopefully, someone can offer some advice. Thanks in advance.
Update: After additional research, I have found the solution to this problem is to enclose the filename in the response header in double-quotes.
I have found the cause of the problem. It turns out that Google Chrome has problems with files that have commas in their filename. When downloading the file via a direct link, Chrome will report that duplicate headers were reported from the server. This has been a long-standing problem with Chrome that has gone un-addressed. Other browsers are not susceptible to this problem. Still, it's a fairly easy problem to troubleshoot and, indeed, when I searched on this error, the first search result had the solution: remove commas from filenames when handling a request from Google Chrome.
However, this wasn't a direct link, it was an AJAX-request, which results in a different exception. In this case, the error provided by Chrome is the cross-origin request exception and this is what made it so difficult to troubleshoot.
So, the tl;dr of it all is to strip out commas in the names of uploaded files.
Another instance I found where this issue occurred is after executing code similar to:
document.domain = '[the exact same domain that the iframe originally had]'
Removing this line of code got rid of this error for me.

WebSocket on IE10 giving a SecurityError

I am currently developing a website under IE10 (on Windows 8), using WebSockets in JavaScript. It runs fine under Firefox 18 and Chrome 25, but on IE10 I get a SecurityError when I establish the connection.
What I am doing seems pretty straghtforward :
websocket = new WebSocket('wss://hello.dev.mydomain.net');
But IE doesn't like it :
SCRIPT5022: SecurityError
The script is on "https://test.dev.mydomain.net" (not the real address obviously).
What bothers me is that if I just double-click the file on my local computer (e.g. file://...) it just works. Even worse: if I use fiddler to monitor HTTP traffic... it also works. Whereas there seems to be no connection at all without fiddler, as detailed in the API's specs. (See below.)
Judging by websocket spec, the exception should also appear on Chrome/Firefox... but it does not. So I doubt it has anything related to HTTP/HTTPS. In any case, I am using a wsS socket on a httpS page... Moreover: when I replace the wss address by another valid server found on an online example, it works.
I don't know if this is relevant, but the IP from test.dev.mydomain.net is 10.14.x.x where hello.dev.mydomain.net is 194.247.x.x. I don't know if it could trigger some kind of security on IE only...
One more thing: I have a certificate for *.dev.mydomain.net, IE does not seems to have problems with it. The script originally resides on a server called my.name.dev.mydomain.net, but since I am accessing it from another URL (I got a redirect since we first thought it could have been some kind of Same Origin Policy issue), I don't see how it could matter. At least I hope it does not...
Any idea is welcomed.
EDIT: adding the sites to the trusted zone does not work either.
It looks like IE throws a SecurityError if you're trying to open a websocket on a local (intranet) domain. To overcome this, you may disable IE's automatic algorithm for recognizing local sites. This can be done in Tools > Internet Options > Security > Local Intranet > Sites.
Uncheck all checkboxes (or only a particular one, if you know how exactly your domain did end up in intranet ones).
Note that IE uses (among other things) its proxy settings to determine local sites: if your domain is listed as excluded from proxying in proxy settings, then it will probably be treated as intranet one. This is why WebSockets work if you enable Fiddler: it modifies IE proxy settings and thus the list of intranet sites changes.
I had this problem in Windows7/IE11 after applying a security patch. For Windows10/Edge is the same story.
As this is a local websocket (ws://localhost) you have to add ws:\\localhost\ to Internet Explorer configurations (Tools > Internet Options > Security > Local Intranet > Sites > Advanced).
In Windows 10/Microsoft Edge you will find this configuration in Control Panel > Internet Options.
UPDATE
The address of your webapp (https://test.dev.mydomain.net) must be added to the local intranet zone too. Note that in the image the webapp address should be added.
Well, my question wasn't that successful, so I'll post the "workaround" I found.
I got another address for the website, in 194.247.. too. This, magically, solved it. Guess IE doesn't like mixing local and external stuff and watches the IP.
Anyways, I hope this may come in handy to anyone who's got the same issue.
If you have a solution to solve the "real" issue by configuring IE, let me know :)
Cheers,
Browsers has a websocket limitation. For example Internet Explorer has default limit of websocket connections set to 6 per host header name. the same limitation is set for WinForms WebBrowser component.
The solution is to add values under key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBSOCKET_MAXCONNECTIONSPERSERVER in registry. Just add DWORD value with executable name , for example iexplore.exe (or your application executable name if you use Web browser component) and set value from range 2..128
Second option how to solve SecurityException is to create multiple subdomains.
The client hostname/IP Address should be same as server IP/Hostname thats listening to otherwise you would get the above error.
1) Make sure whether server hostname configured to listen at IP/localhost etc andif not explicitly specify the hostname ast server
2) use the same hostname in the client. THis will solve the issue. It worked for me...
I encountered the error (although it did not say the SCRIPT5022 part, rather it just reports "ScriptError"). I got around the issue by clicking on "Trusted Sites" and then adding the machine hosting the remote websocket. Note, to add to trusted sites,
I had to supply the address without the "ws://" part (like just mymahcine.mydomain.com)
I had to uncheck the box that says "Require server verification https:// " option.
After I was done adding the domain, I re-checked the box "Require server verification (https://). I would recommend everyone to do the same. Unchecking the box is only a workaround to add sites that don't begin with https (rather ws:// in my case)
I had the same issue at one of my customer's environment.
It turned out that they had a proxy configuration that did not allow the connection to the WebSocket endpoint directly and did not support the WebSocket protocol.
The temporary solution was to disable using the proxy and everything started working. The long term solution is to edit the proxy's configuration (.pac file) to exclude the address of the WebSocket endpoint.
To disable the proxy, go to: Internet Explorer Options > Connections tab > LAN settings button > un-check Automatically detect settings.
Hope this helps someone.
In addition to making sure that the internet zone is not localhost (as in above answers), ensure that if https is used, then wss should be used.
This is not an issue in other browsers, but IE is abit more finicky.

Categories