I am trying to make a simple POST request and I am still unsuccessful.
Headers change from
Encoding: UTF-8 Http-Method: POST Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
to
Http-Method: OPTIONS
Content-Type:
I understand that when I try to access my server using Google Closure XhrIo , it causes preflight and fails my POST request.
But Firefox extension app RESTClient and also a similar Chrome app can access using XMLHttpRequest and they don't cause preflight. How and why ?
PS: I am not a JS pro and I fail to understand the intricacies of this code http://code.google.com/p/restclient/source/browse/extension/chrome/content/restclient.js.
Any help appreciated
Eddie.
Found this piece of valuable information on HTML5Rocks.com
CROSS-DOMAIN FROM CHROME EXTENSIONS
Chrome extensions support cross-domain requests in a two different ways:
Include domain in manifest.json - Chrome extensions can make cross-domain requests to any domain if the domain is included in the "permissions" section of the manifest.json file:
"permissions": [ "http://*.html5rocks.com"] The server doesn't need to include any additional CORS headers or do any more work in order for the request to succeed.
CORS request - If the domain is not in the manifest.json file, then the Chrome extension makes a standard CORS request. The value of the Origin header is "chrome-extension://[CHROME EXTENSION ID]". This means requests from Chrome extensions are subject to the same CORS rules described in this article.
Related
I am trying to make the following requests on GitHub using a Chrome extension:
GET github.com/<user>/<repo>/info/refs?service=git-receive-pack
POST github.com/<user>/<repo>/git-receive-pack
Doing so, I receive a Bad Request Error (400). My understanding is that the error is due to the CORS policy. Actually, if I proxify the URL using CORS proxy servers (like this), there is no issue.
Is there any way of handling this CORS issue in the Chrome extension?
P.S. If I use the extension to make the same requests on GitLab (without using a proxy server), there is no issue.
This question already has answers here:
Disable same origin policy in Chrome
(35 answers)
Closed 1 year ago.
We are facing an issue where using Chrome request via XMLHTTPRequest is getting failed with below error:
Failed to load <server url>: No 'Access-Control-Allow-Origin' header
is present on the requested resource. Origin '<client domain>' is
therefore not allowed access.
This error is Chrome specific since we are not getting this issue in IE. Is there anyway to bypass this error in JavaScript.
Basically, for development purposes only, you can start the Chrome Browser in relaxed mode using the disable-web-security flag:
Here's how to do it on windows (Credit to https://alfilatov.com/posts/run-chrome-without-cors/)
Right click on desktop, add new shortcut
Add the target as "[PATH_TO_CHROME]\chrome.exe" --disable-web-security --disable-gpu --user-data-dir=~/chromeTemp
Click OK.
The directory in 'user-data-dir' must have read/write permissions for Chrome.
You will get a warning banner in Chrome notifying about reduces security, because that is actually what you have here. USE ONLY FOR TESTING.
Note: This answer builds on the link-only answer by Franco Fontana which was deleted because of link-only but the link actually helped me.
No, fortunately there is not.
The same-origin policy is an security concept implemented by browsers to prevent Javascript code from making requests against a different origin/domain than the one from which it was served. So enabling developers to bypass this from Javascript would be a bad thing.
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application makes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.
Source: Cross-Origin Resource Sharing (CORS)
If you're in control of the API:
Add an Access-Control-Allow-Origin header containing the domain your requests are originating from.
If you're not in control of the API:
Ask the developer of the API to have your domain added to an Access-Control-Allow-Origin header.
EDIT:
Adding the correct header will not 'make the request an OPTIONS request while the server only accepts POST'.
The OPTIONS request is a preflight request to check to see if the CORS call can actually be made. If the preflight request has the correct header, the POST request will follow as you can see in the image below:
You can find all of the basic CORS information in the article Understanding CORS
Although its limited, can try to use CORS anywhere https://github.com/Rob--W/cors-anywhere or the chrome extension here that allows you to bypass CORS (make sure you turn this off when not testing as it will cause issues with requests from other websites)
I am trying to GET liststatus from the Webhdfs rest api, but getting the following error.
XMLHttpRequest cannot load http://<IP>:50070/webhdfs/v1/?op=LISTSTATUS. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.
It loads successfully when I try to access through curl. But it fails when I try to get it using AngularJS $http.get.
Is there any way to enable Cross domain access in Hadoop core-site.xml or somewhere else?
If I understood it right you are doing an XMLHttpRequest to a different domain than your page is on. So the browser is blocking it as it usually allows a request in the same origin for security reasons. You need to do something different when you want to do a cross-domain request. A tutorial about how to achieve that is Using CORS.
When you are using postman they are not restricted by this policy. Quoted from Cross-Origin XMLHttpRequest:
Check it in Firefox browser it may work or else ..
I believe this might likely be that Chrome does not support localhost to go through the Access-Control-Allow-Origin -- see Chrome issue
To have Chrome send Access-Control-Allow-Origin in the header, just alias your localhost in your /etc/hosts file to some other domain, like:
127.0.0.1 localhost yourdomain.com
Then if you'd access your script using yourdomain.com instead of localhost, the call should succeed.
(or)
That's problem of the server. You have to setup response headers on server side.
I'm trying to access the Adobe TypeKit API's via javascript, using AngularJS.
Using $http.get(https://typekit.com/api/v1/json/kits?token=myToken) fails on authenticated requests, with error:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.
If I use $http.jsonp(...) un-authenticated requests are succesfull, this is probably due to Adobe's CORS policies, but as stated in the typekit documentation
For security reasons, authenticated API requests are currently unavailable with callbacks.
So, using jsonp, I can't access many of the endpoints provided by the API's.
What I don't understand is that the same exact request that fails in angular, succeds if I execute it with postman or with chrome itself. I tryied setting the request headers exactly the same as in postman, but didn't work. Tried all sorts of headers settings, but nothing changed.
Any thoughts?
can you disable the chrome web security and then give it a try.To disable the web security open your terminal and type the following /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security --allow-file-access-from-files --allow-file-access --user-data-dir=~/chrome-test/ spec/runner.html
I'm intending to add security for our Javascript code which gets embedded on other sites - eg: like analytics code.
The user copies 4-5 lines of the code and puts it on his site. The code actually downloads the real script as the next step.
I have been recommended to use CORS instead of the current JSONP calls as I can restrict the domains.
As I understand, the CORS would work only if the html page which will add my scripts needs to add access domains and if I add the access domains for the the js file, it wouldn't work.
Is the CORS for the final js or the html page intending to use my script?
Edit:
Since it's confusing to the users, I have made it more simple.
HTML in domain A adds my script from Domain B like Google analytics. Can I add access-domains: while rendering my JS or should the HTML add the access-domains in the response?
There is a good explanation from wiki for this question:
CORS can be used as a modern alternative to the JSONP pattern. While JSONP supports only the GET request method, CORS also supports other types of HTTP requests. Using CORS enables a web programmer to use regular XMLHttpRequest, which supports better error handling than JSONP. On the other hand, JSONP works on legacy browsers which predate CORS support. CORS is supported by most modern web browsers. Also, while JSONP can cause cross-site scripting (XSS) issues where the external site is compromised, CORS allows websites to manually parse responses to ensure security.
As I understand, the CORS would work only if the html page which will add my scripts needs to add access domains
You can access all domains via:
Access-Control-Allow-Origin: *
Also now CORS has good support.
P.S. IE8-9 has own imlementation by XDomainRequest.
CORS works by having your server output the Access-Control-Allow-Origin header containing the allowed domains. The sites that make ajax requests to your server don't need to do anything special to enable CORS, there is no configuration required. The sites just simply make normal XHR requests and the browser will internally handle the CORS.
You control the CORS access from the header on your server. In CORS, you can also control the HTTP verbs that are allowed, for example POST or GET (Access-Control-Allow-Methods) or the permitted request headers (Access-Control-Allow-Headers).
Note that IE8 doesn't support the CORS XHR, Microsoft decided to create their own CORS implementation with XDomainRequest. So if any of the sites that call your server want to support IE8, they will need to use XDomainRequest instead of XMLHttpRequest. There is no support for CORS in IE7 or eariler - not even XDomainRequest.