The Error “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”, is an error that is invoked whenever you are coding in javascript and trying to get data from a REST API. Given below is the snippet of the error you might get:
No 'Access-Control-Allow-Origin' header is present on the requested resource.I would like to share with you the steps I took to fix the “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”
Why No ‘Access-Control-Allow-Origin’ header is present on the requested resource Error is Seen?
The error, “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.” is seen because you may be trying to fetch data from within your local host rather you have to use a Cross-Origin Resource Sharing (CORS).
To use your CORS you will have to use it in an appropriate way in order to avoid “No Access-Control-Allow-Origin header” errors and CORS preflight errors.
The detailed solution to fix the error “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”, is given below:
How to fix No ‘Access-Control-Allow-Origin’ header is present on the requested resource React Native App Error?
To fix the error, You will have to use a Cross-Origin Resource Sharing or CORS, instead of using your local host to fetch data. To use your CORS you will have to use it in an appropriate way in order to avoid “No Access-Control-Allow-Origin header” errors and CORS preflight error.
An HTTP-header based system called Cross-Origin Resource Sharing (CORS) enables a server to specify any origins (domain, scheme, or port) other than its own from which a browser should be able to load resources.
In order to verify that the server hosting the cross-origin resource would allow the actual request, CORS additionally uses a method wherein browsers send a “preflight” request to the server hosting the resource.
The browser transmits headers that specify the HTTP method and headers that will be used in the actual request during that preflight.
An example of a cross-origin request is the front-end JavaScript code that is served from https://testnc-a.com and makes a request to https://testnc-b.com/data.json using XMLHttpRequest.
Browsers limit cross-origin HTTP queries made by scripts for security reasons. For instance, the Fetch API and XMLHttpRequest both adhere to the same-origin rule.
This implies that unless the answer from other origins contains the appropriate CORS headers, a web application utilizing those APIs may only request resources from the origin the application was loaded from.
Secure cross-origin requests and data transfers between browsers and servers are supported via the CORS protocol. To reduce the risks of cross-origin HTTP requests, modern browsers employ CORS in APIs like XMLHttpRequest or Fetch.
To fix the error, “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”, you have to follow the below-mentioned steps:
Step 1: CORS proxy to avoid “No Access-Control-Allow-Origin header”
If you do not have control over the server to which your frontend code is sending a request, and the problem with the response from that server is just a lack of the required Access-Control-Allow-Origin header, you may still get things to work by passing the request via a CORS proxy.
You can quickly deploy your own proxy to Heroku, using commands given below:
git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku masterOnce you run the above mentioned commands, you will end up with your own CORS Anywhere server running.
Then you will have to, prefix your request URL with the URL for your proxy:
https://..........https://testnc.comOnce you add the proxy URL as a prefix causes the request to get made through your proxy, which does the below mentioned things:
- It can forwards your request to https://testnc.com.
- It can receives your response from https://testnc.com.
- It has the ability to add the Access-Control-Allow-Origin header to the response.
- It can also pass that response, with that added header, back to the requesting frontend code.
Your browser could then allow the frontend code to access all the response, because that response with the Access-Control-Allow-Origin response header is what the will browser see.
This will works even though the request is one that triggers browsers to do a CORS preflight OPTIONS request, in that case, the proxy also sends the Access-Control-Allow-Headers and Access-Control-Allow-Methods headers needed to make the preflight succeed.
Step 2: Avoid the CORS preflight
The code which you may use in your project file can also trigger a CORS preflight—since it sends an Authorization header.
In contrast to basic requests, “preflighted” requests use an HTTP OPTIONS method request to the resource on the other origin to establish if the real request may be sent. These cross-origin requests are preflighted because they could have an impact on user information.
An example of a request that will be preflighted is as follows:
const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'text/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>NC</name></person>');The given example generates an XML body to submit along with the POST request. Additionally, the HTTP X-PINGOTHER request header is non-standard.
Although not a part of HTTP/1.1, these headers are often helpful to web applications. This request is preflighted because it includes a custom header and has a Content-Type of text/xml.
Even without that, the Content-Type: application/json header will also trigger a preflight.
What is the meaning of “preflight”: 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.
In order 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 isThe 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, AuthorizationIn case the OPTIONS response does not include those headers, the browser would stop right there and would have never attempted to send the POST request.
Your response’s HTTP status code must be a 2xx, such as 200 or 204. If there is any other status code, the browser must exit immediately.
There are two ways to avoid getting a preflight:
- If the server did not need an Authorization request header and instead relied on authentication data included in the body of the POST request or as a query parameter.
- If the server did not require a Content-Type: application or JSON media type in the POST body and instead accepted the POST body as application/x-www-form- with a parameter called json whose value is the JSON data.
How to fix “Access-Control-Allow-Origin header must not be the wildcard” problems
In case you are getting the error “Access-Control-Allow-Origin header must not be the wildcard”, you have to know that 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 *. Rather the value in that case must exactly match your frontend code’s origin.
In case you control the server you are sending the request to, a common way to deal with the above mentioned error 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. For example with nginx your code will look like the below mentioned code:
add_header Access-Control-Allow-Origin $http_originThe above mentioned code is just an example; other web server systems have similar ways to echo origin values.
In case you are using google chrome and tried to use the chrome CORS plugin and still face the same error, you will have to follow the below mentioned information:
The Chrome CORS plugin apparently just directly injects an Access-Control-Allow-Origin: * header into the response the browser sees.
For the Access-Control-Allow-Origin response-header value, the server must give an exact origin rather than the wildcard “*”; for illustration: https://example.com Access-Control-Allow-Origin
As far as the frontend JavaScript code for the fetch(…) request you will have to remove the below mentioned lines:
headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
headers.append('Access-Control-Allow-Credentials', 'true');The Access-Control-Allow-* headers are response headers. Please do not send them in requests. The only effect of that is to trigger a browser to do a preflight.
This should fix the error, “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”
Conclusion
To fix the error “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”, you will have to use a Cross-Origin Resource Sharing or CORS, instead of using your local host to fetch data.
To use your CORS you will have to use it in an appropriate way in order to avoid “No Access-Control-Allow-Origin header” errors and CORS preflight error.