I am trying to enable HTTP access control (CORS) on a site using a .htaccess file with the following code:
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Origin "Content-Type"
Header set Access-Control-Allow-Methods: "GET"
But I keep getting the error
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at [DOMAINNAME] (Reason: CORS header 'Access-Control-Allow-Origin' does not match 'Content-Type').
What am I doing wrong? Every tutorial I've found seems to suggest it should work.
-edit-
In Chrome the debug tools give me this additional info:
Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header contains the invalid value 'Content-Type'.
Try with:
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Headers "Content-Type"
Header set Access-Control-Allow-Methods "GET"
Related
I build my own API which is running on port 5000. Whenever I want to make a request to it , I get the following error:
Access to XMLHttpRequest at 'http://localhost:5000/user' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I already did some research but the only thing that seems to work is a chrome extension, which isnt ideal.
Here's what i did :
const config = {
headers : {
'Content-Type' : 'application/json',
'Access-Control-Allow-Origin': '*'
}
};
Simply, browsers block responses if server does not allow CORS. So if you are using NodeJS at your API, use this library.
I use my Web application in a subdomain also, I use a different subdomain for the interface objects.
That's the problem: CORS
Fonts are not installed because of cors barrier.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at
https://assets.example.com/fonts/simple-line-iconsc05f.ttf?thkwh4.
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Application:
https://ap.example.com
Assets:
https://assets.example.com
I added the root of Web application, .htaccess file:
<FilesMatch "\.(ttf|otf|eot|woff|svg|woff2)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
Also, nginx.conf file:
server {
...
location ~* \.(eot|ttf|woff|woff2)$ {
add_header 'Access-Control-Allow-Origin' '*';
}
...
}
Nevertheless, I'm still stuck in the cors barrier.
It has been tried many times with cache and different browsers. The result has not changed.
You can try this:
location / {
if ($request_filename ~* ^.*?/([^/]*?)$) {
set $filename $1;
}
if ($filename ~* ^.*?\.(eot)|(ttf)|(woff)|(jpg)|(png)|(css)|(js)$){
add_header 'Access-Control-Allow-Origin' "*";
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Headers' 'User-Agent,Keep-Alive,Content-Type,X-Api-Token';
}
}
#Editor, whilst the solution from #Sahipsiz might work, CORS is a complex topic, and as per my previous comment, that solution is technically incorrect (even though it may have solved your symptom, the underlying problem is still there)...
First off, if your browser decides that CORS is in play, it will send the Origin request header, containing the full domain of the requesting page, e.g.:
Origin: https://ap.example.com
If the request doesn't include the Origin request header, then this isn't a CORS request, and you don't need to do anything CORS-related.
If you are sure that you don't need support for cookies to be passed to/from the assets domain, you can simply respond to a CORS request by including this response header:
Access-Control-Allow-Origin: *
However, if you do need cookie support, you'll need to include these two response headers:
Access-Control-Allow-Origin: <value of Origin request header>
Access-Control-Allow-Credentials: true
So in your case, you would respond with this:
Access-Control-Allow-Origin: https://ap.example.com
Access-Control-Allow-Credentials: true
In some cases (which may well not apply to you, since you're just retrieving fonts), prior to making the main GET/POST/PUT/DELETE request, your browser will first make an additional 'preflight' OPTIONS request - this is basically the browser asking permission to make the main request. The OPTIONS request includes a number of CORS-specific request headers, and you need to return some 'matching' CORS response headers to this OPTIONS request (but no response body). If you do this correctly, the browser will then make the main request.
For that OPTIONS request, you should return the following CORS response headers:
Access-Control-Allow-Origin: <value of Origin request header>
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: <value of Access-Control-Request-Method request header>
Access-Control-Allow-Headers: <value of Access-Control-Request-Headers request header>
Those response headers tell the browser that you are OK with the GET/POST/DELETE/PUT request it's about to make.
You can optionally also pass the following response header to the OPTIONS request (in addition to the four defined above):
Access-Control-Max-Age: 86400
which tells the browser to cache the OPTIONS response headers - this stops it from making the preflight request every time.
CORS ain't easy.
I want to use fineuploader with cross domain.
I get Request header field Cache-Control is not allowed by Access-Control-Allow-Headers in preflight response. error.
My fineuploader config is:
request: {
endpoint: "http://api.polskieszlaki.local/4adm/zdjecia/fileupload",
},
cors: {
expected: true,
},
On my apache server in .htaccess I have
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
I have no firther ideas to make it work.
The message cited in the question indicates you must change your .htaccess to have Cache-Control in the value set for the Access-Control-Allow-Headers response header, and because the Fine Uploader docs indicate it sends the X-Requested-With header, then altogether you need:
Header set Access-Control-Allow-Headers "Cache-Control, Content-Type, Authorization, X-Requested-With"
The MDN docs for the Access-Control-Allow-Headers response header explain:
The Access-Control-Allow-Headers header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
I have an API server api.example.com and two websites a.example.com, b.example.com. To enable CORS, I set up CORS headers for them.
An XHR request from a.example.com will get the response headers from api.example.com
access-control-allow-credentials: true
access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: https://a.example.com
access-control-max-age: 0
vary: origin
Similarly, an XHR request from b.example.com will get the response headers from api.example.com
access-control-allow-credentials: true
access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: https://b.example.com
access-control-max-age: 0
vary: origin
When I fetches resource GET api.example.com/articles/1 in a.example.com and then go to b.example.com do the same action to fetch the resource. The browser will use if-none-match headers to get the resource and receives a 304 response code from server. Then it complains that Access-Control-Allow-Origin header has a value https://a.example.com that is not equal to the supplied origin. Origin https://b.example.com is therefore not allowed access.
I think browser uses its cache when 304 is responded and find out Access-Control-Allow-Origin is cached as a.example.com's resource therefore refuse to fulfill the request.
How can I mitigate the issue here? Any thought?
Requests are cached, including its content and headers.
When you access a the first time. The response is generated and saved in the cache.
When you access b afterwards. The 304 response comes with no header and no content, all it does is instruct the browser to use the cache. The cached response has headers for the other site and it throws an access error.
These two requests should not be answered with a 304 since they are not equivalent.
If-None-Match means that pages are identified with en ETag. An arbitrary string generated by the application to identify a cachable version of a page.
You should modify the application to generate different ETag for different Origin.
I have a page 'https://localhost:58525' with content from API json response.
Api url 'http://localhost:51492/api/claimrequest/SearchNewClaimRequests'.
Fidder Autoresponder:
I added Autoresponder rule with request url pattern 'EXACT:http://localhost:51492/api/claimrequest/SearchNewClaimRequests' with response from a txt file.
Am getting below error when I try to load the page.
XMLHttpRequest cannot load http://localhost:51492/api/claimrequest/SearchNewClaimRequests. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:58525' is therefore not allowed access.
Is there any way to add cross origin headers?