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.
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 master
Once 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:
Once 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
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
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 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
In 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
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_origin
The 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
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');
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.”
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.