Why am I seeing an origin is not allowed by Access-Control-Allow-Origin error here?
Javascript is limited when making ajax requests outside of the current domain.
- Ex 1: your domain is example.com and you want to make a request to test.com => you cannot.
- Ex 2: your domain is example.com and you want to make a request to inner.example.com => you cannot.
- Ex 3: your domain is example.com:80 and you want to make a request to example.com:81 => you cannot
- EX 4: your domain is example.com and you want to make a request to example.com => you can.
Javascript is limited by the "same origin policy" for security reasons so that a malicious script cannot contact a remote server and send sensitive data.
jsonp is a different way to use javascript. You make a request and results are encapsulated into a callback function which is run in the client. It's the same as linking a new script tag into the head part of your html (you know that you can load scripts from different domains than yours here).
However, to use jsonp the server must be configured properly. If this is not the case you cannot use jsonp and you MUST rely on a server side proxy (PHP, ASP, etc.). There are plenty of guides related to this topic, just google it!
Origin origin is not allowed by Access-Control-Allow-Origin
Since they are running on different ports, they are different JavaScript origin
. It doesn't matter that they are on the same machine/hostname.
You need to enable CORS on the server (localhost:8080). Check out this site: http://enable-cors.org/
All you need to do is add an HTTP header to the server:
Access-Control-Allow-Origin: http://localhost:3000
Or, for simplicity:
Access-Control-Allow-Origin: *
Thought don't use "*" if your server is trying to set cookie and you use withCredentials = true
when responding to a credentialed request, server must specify a domain, and cannot use wild carding.
You can read more about withCredentials
here
Origin is not allowed by Access-Control-Allow-Origin
I wrote an article on this issue a while back, Cross Domain AJAX.
The easiest way to handle this if you have control of the responding server is to add a response header for:
Access-Control-Allow-Origin: *
This will allow cross-domain Ajax. In PHP, you'll want to modify the response like so:
<?php header('Access-Control-Allow-Origin: *'); ?>
You can just put the Header set Access-Control-Allow-Origin *
setting in the Apache configuration or htaccess file.
It should be noted that this effectively disables CORS protection, which very likely exposes your users to attack. If you don't know that you specifically need to use a wildcard, you should not use it, and instead you should whitelist your specific domain:
<?php header('Access-Control-Allow-Origin: http://example.com') ?>
Origin 'url' is not allowed by Access-Control-Allow-Origin
Ajax requests are limited by the browser's Same Origin Policy. In a nutshell, that means that you can't talk directly to a server via ajax that isn't on the same domain as the page your script is running in. So, unless you're developing a page for google.com, you can't talk to google.com directly.
There are work-arounds for this limitation involving the insertion of script tags (JS files loaded via script tags are not subject to the same origin policy) and then using JSONP callbacks to communicate data results back to your main script from those script tags. That is probably what you need to do here if the API you're attempting to use supports it.
jQuery will help you a lot here as it can automatically turn an ajax call into a JSONP call that is loaded via script tags and can work in cross domain situations. According to the jQuery doc for it's ajax function, it will do this automatically if it sees "callback=" in the parameter string for the ajax call or if you set the crossDomain option.
Why does my JavaScript code receive a No 'Access-Control-Allow-Origin' header is present on the requested resource error, while Postman does not?
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.
When you are using Postman they are not restricted by this policy. Quoted from Cross-Origin XMLHttpRequest:
Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, but they're limited by the same origin policy. Extensions aren't so limited. An extension can talk to remote servers outside of its origin, as long as it first requests cross-origin permissions.
No 'Access-Control-Allow-Origin' header is present on the requested resource from Azure App Service API
The issue was that even though CORS was enabled in the application code, there is also a CORS page in the Azure portal where a list of origins must be added.
To find it just Search for 'CORS' in the Azure portal search bar and add the URL of the site that you would like to have access to your endpoints.
No 'Access-Control-Allow-Origin' header is present on the requested resource—when trying to get data from a REST API
This answer covers a lot of ground, so it’s divided into three parts:
- How to use a CORS proxy to avoid “No Access-Control-Allow-Origin header” problems
- How to avoid the CORS preflight
- How to fix “Access-Control-Allow-Origin header must not be the wildcard” problems
How to use a CORS proxy to avoid “No Access-Control-Allow-Origin header” problems
If you don’t control the server your frontend code is sending a request to, and the problem with the response from that server is just the lack of the necessary Access-Control-Allow-Origin
header, you can still get things to work—by making the request through a CORS proxy.
You can easily run your own proxy with code from https://github.com/Rob--W/cors-anywhere/.
You can also easily deploy your own proxy to Heroku in just 2-3 minutes, with 5 commands:
git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master
After running those commands, you’ll end up with your own CORS Anywhere server running at, e.g., https://cryptic-headland-94862.herokuapp.com/
.
Now, prefix your request URL with the URL for your proxy:
https://cryptic-headland-94862.herokuapp.com/https://example.com
Adding the proxy URL as a prefix causes the request to get made through your proxy, which:
- Forwards the request to
https://example.com
. - Receives the response from
https://example.com
. - Adds the
Access-Control-Allow-Origin
header to the response. - Passes that response, with that added header, back to the requesting frontend code.
The browser then allows the frontend code to access the response, because that response with the Access-Control-Allow-Origin
response header is what the browser sees.
This works even if the request is one that triggers browsers to do a CORS preflight OPTIONS
request, because in that case, the proxy also sends the Access-Control-Allow-Headers
and Access-Control-Allow-Methods
headers needed to make the preflight succeed.
How to avoid the CORS preflight
The code in the question triggers a CORS preflight—since it sends an Authorization
header.
https://developer.mozilla.org/docs/Web/HTTP/Access_control_CORS#Preflighted_requests
Even without that, the Content-Type: application/json
header will also trigger a preflight.
What “preflight” means: before the browser tries the POST
in the code in the question, it first sends an OPTIONS
request to the server, to determine if the server is opting-in to receiving a cross-origin POST
that has Authorization
and Content-Type: application/json
headers.
It works pretty well with a small curl script - I get my data.
To properly test with curl
, you must emulate the preflight OPTIONS
the browser sends:
curl -i -X OPTIONS -H "Origin: http://127.0.0.1:3000" \
-H 'Access-Control-Request-Method: POST' \
-H 'Access-Control-Request-Headers: Content-Type, Authorization' \
"https://the.sign_in.url"
…with https://the.sign_in.url
replaced by whatever your actual sign_in
URL is.
The response the browser needs from that OPTIONS
request must have headers like this:
Access-Control-Allow-Origin: http://127.0.0.1:3000
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, Authorization
If the OPTIONS
response doesn’t include those headers, the browser will stop right there and never attempt to send the POST
request. Also, the HTTP status code for the response must be a 2xx—typically 200 or 204. If it’s any other status code, the browser will stop right there.
The server in the question responds to the OPTIONS
request with a 501 status code, which apparently means it’s trying to indicate it doesn’t implement support for OPTIONS
requests. Other servers typically respond with a 405 “Method not allowed” status code in this case.
So you’ll never be able to make POST
requests directly to that server from your frontend JavaScript code if the server responds to that OPTIONS
request with a 405 or 501 or anything other than a 200 or 204 or if doesn’t respond with those necessary response headers.
The way to avoid triggering a preflight for the case in the question would be:
- if the server didn’t require an
Authorization
request header but instead, e.g., relied on authentication data embedded in the body of thePOST
request or as a query param - if the server didn’t require the
POST
body to have aContent-Type: application/json
media type but instead accepted thePOST
body asapplication/x-www-form-urlencoded
with a parameter namedjson
(or whatever) whose value is the JSON data
How to fix “Access-Control-Allow-Origin header must not be the wildcard” problems
I am getting another error message:
The value of the 'Access-Control-Allow-Origin' header in the response
must not be the wildcard '*' when the request's credentials mode is
'include'. Origin 'http://127.0.0.1:3000
' is therefore not allowed
access. The credentials mode of requests initiated by the
XMLHttpRequest is controlled by the withCredentials attribute.
For requests that have credentials, browsers won’t let your frontend JavaScript code access the response if the value of the Access-Control-Allow-Origin
header is *
. Instead the value in that case must exactly match your frontend code’s origin, http://127.0.0.1:3000
.
See Credentialed requests and wildcards in the MDN HTTP access control (CORS) article.
If you control the server you’re sending the request to, a common way to deal with this case is to configure the server to take the value of the Origin
request header, and echo/reflect that back into the value of the Access-Control-Allow-Origin
response header; e.g., with nginx:
add_header Access-Control-Allow-Origin $http_origin
But that’s just an example; other (web) server systems have similar ways to echo origin values.
I am using Chrome. I also tried using that Chrome CORS Plugin
That Chrome CORS plugin apparently just simplemindedly injects an Access-Control-Allow-Origin: *
header into the response the browser sees. If the plugin were smarter, what it would be doing is setting the value of that fake Access-Control-Allow-Origin
response header to the actual origin of your frontend JavaScript code, http://127.0.0.1:3000
.
So avoid using that plugin, even for testing. It’s just a distraction. To test what responses you get from the server with no browser filtering them, you’re better off using curl -H
as above.
As far as the frontend JavaScript code for the fetch(…)
request in the question:
headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
headers.append('Access-Control-Allow-Credentials', 'true');
Remove those lines. The Access-Control-Allow-*
headers are response headers. You never want to send them in requests. The only effect of that is to trigger a browser to do a preflight.
Origin http://localhost is not allowed by Access-Control-Allow-Origin.?
You've got two ways to go forward:
JSONP
If this API supports JSONP
, the easiest way to fix this issue is to add &callback
to the end of the URL. You can also try &callback=
. If that doesn't work, it means the API does not support JSONP
, so you must try the other solution.
Proxy Script
You can create a proxy script on the same domain as your website in order to avoid the cross-origin issues. This will only work with HTTP URLs, not HTTPS URLs, but it shouldn't be too difficult to modify if you need that.
<?php
// File Name: proxy.php
if (!isset($_GET['url'])) {
die(); // Don't do anything if we don't have a URL to work with
}
$url = urldecode($_GET['url']);
$url = 'http://' . str_replace('http://', '', $url); // Avoid accessing the file system
echo file_get_contents($url); // You should probably use cURL. The concept is the same though
Then you just call this script with jQuery. Be sure to urlencode
the URL.
$.ajax({
url : 'proxy.php?url=http%3A%2F%2Fapi.master18.tiket.com%2Fsearch%2Fautocomplete%2Fhotel%3Fq%3Dmah%26token%3D90d2fad44172390b11527557e6250e50%26secretkey%3D83e2f0484edbd2ad6fc9888c1e30ea44%26output%3Djson',
type : 'GET',
dataType : 'json'
}).done(function(data) {
console.log(data.results.result[1].category); // Do whatever you want here
});
The Why
You're getting this error because of XMLHttpRequest same origin policy, which basically boils down to a restriction of ajax requests to URLs with a different port, domain or protocol. This restriction is in place to prevent cross-site scripting (XSS) attacks.
More Information
Our solutions by pass these problems in different ways.
JSONP
uses the ability to point script tags at JSON (wrapped in a javascript function) in order to receive the JSON. The JSONP page is interpreted as javascript, and executed. The JSON is passed to your specified function.
The proxy script works by tricking the browser, as you're actually requesting a page on the same origin as your page. The actual cross-origin requests happen server-side.
Related Topics
How to Detect Overflow in Div Element
"Scroll" to the Very Right of a Long Text Input
How to Detect Support for the HTML5 "Download" Attribute
Browsers Automatically Evaluate Hex or Hsl Colors to Rgb When Setting via Element.Style.Background
Restart a Gif Animation Without Reloading the File
Why Does Reflow Need to Be Triggered for CSS Transitions
Get All Computed Style of an Element
Extract the Current Dom and Print It as a String, with Styles Intact
Change Svg Fill Color in :Before or :After CSS
Convert JavaScript-Generated Svg to a File
Iis 7.5 No Images CSS Js Showing
How to Toggle Class Using Pure JavaScript in HTML
Most Elegant Way to Force a Textarea Element to Line-Wrap, *Regardless* of Whitespace
Getelementsbyclassname to Change the Style of Elements When Event Occurs
Convert CSS Width String to Regular Number