Header set Access-Control-Allow-Origin in .htaccess doesn't work - .htaccess

I can't figure out why my .htaccess header settings doesn't work.
My .htaccess file content:
Header set Access-Control-Allow-Origin *
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Allow-Headers "*"
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]
But when I remove Header's and add them in index.php then everything works fine.
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS");
header("Access-Control-Allow-Headers: *");
What am i missing?

This should work:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"

Just for the record, I was running into the exact same problem and none of the answers worked.
I used a headers checker tool: http://www.webconfs.com/http-header-check.php
I was testing with my IP (http://192.0.2.1/upload) and what came back was the following:
HTTP/1.1 301 Moved Permanently =>
Date => Sat, 10 Jan 2015 04:03:35 GMT
Server => Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1
Location => http://192.0.2.1/upload/
Content-Length => 380
Connection => close
Content-Type => text/html; charset=iso-8859-1
There was a redirection happening and the AJAX request does not honor/follow redirects.
It turned out to be the missing slash at the end of the domain (http://192.0.2.1/upload/)
I tested again with slash at the end and I got this below. Added a slash in the script too, and it was now working.
HTTP/1.1 200 OK =>
Date => Sat, 10 Jan 2015 04:03:53 GMT
Server => Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1
X-Powered-By => PHP/5.3.8
Access-Control-Allow-Origin => *
Access-Control-Allow-Methods => PUT, GET, POST, DELETE, OPTIONS
Access-Control-Allow-Headers => *
Content-Length => 1435
Connection => close
Content-Type => text/html
Use this tool to test if your headers are good and to troubleshoot what is happening.

I have a shared hosting on GoDaddy. I needed an answer to this question, too, and after searching around I found that it is possible.
I wrote an .htaccess file, put it in the same folder as my action page. Here are the contents of the .htaccess file:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"
Here is my ajax call:
$.ajax({
url: 'http://www.mydomain.com/myactionpagefolder/gbactionpage.php', //server script to process data
type: 'POST',
xhr: function() { // custom xhr
myXhr = $.ajaxSettings.xhr();
if(myXhr.upload){ // check if upload property exists
myXhr.upload.addEventListener('progress',progressHandlingFunction, false); // for handling the progress of the upload
}
return myXhr;
},
//Ajax events
beforeSend: beforeSendHandler,
success: completeHandler,
error: errorHandler,
// Form data
data: formData,
//Options to tell JQuery not to process data or worry about content-type
cache: false,
contentType: false,
processData: false
});
See this article for reference:
Header set Access-Control-Allow-Origin in .htaccess doesn't work

Be careful on:
Header add Access-Control-Allow-Origin "*"
This is not judicious at all to grant access to everybody. It's preferable to allow a list of know trusted host only...
Header add Access-Control-Allow-Origin "http://aaa.example"
Header add Access-Control-Allow-Origin "http://bbb.example"
Header add Access-Control-Allow-Origin "http://ccc.example"
Regards,

I activated the Apache module headers a2enmod headers, and the issue has been solved.

Try this in the .htaccess of the external root folder
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
Be careful with doing Header add Access-Control-Allow-Origin "*" This is not judicious at all to grant access to everybody. I think you should user:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://example.com"
</IfModule>

I +1'd Miro's answer for the link to the header-checker site http://www.webconfs.com/http-header-check.php. It pops up an obnoxious ad every time you use it, but it is, nevertheless, very useful for verifying the presence of the Access-Control-Allow-Origin header.
I'm reading a .json file from the javascript on my web page. I found that adding the following to my .htaccess file fixed the problem when viewing my web page in IE 11 (version 11.447.14393.0):
<FilesMatch "\.(json)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
I also added the following to /etc/httpd.conf (Apache's configuration file):
AllowOverride All
The header-checker site verified that the Access-Control-Allow-Origin header is now being sent (thanks, Miro!).
However, Firefox 50.0.2, Opera 41.0.2353.69, and Edge 38.14393.0.0 all fetch the file anyhow, even without the Access-Control-Allow-Origin header. (Note: they might be checking IP addresses, since the two domains I was using are both hosted on the same server, at the same IPv4 address.)
However, Chrome 54.0.2840.99 m (64-bit) ignores the Access-Control-Allow-Origin header and fails anyhow, erroneously reporting:
No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin '{mydomain}' is therefore not allowed access.
I think this has got to be some sort of "first." IE is working correctly; Chrome, Firefox, Opera and Edge are all buggy; and Chrome is the worst. Isn't that the exact opposite of the usual case?

After spending half a day with nothing working.
Using a header check service though everything was working.
The firewall at work was stripping them

try this:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Credentials true
Header set Access-Control-Allow-Origin "your domain"
Header set Access-Control-Allow-Headers "X-Requested-With"
</IfModule>
It's preferable to allow a list of know trusted host.

If anyone else is trying this, the most upvoted answer should work. However, if you are having issues it could be possible the browser has cached the REQUEST. To confirm append a query string.

To complete the most upvoted answer, I want to add the case whenever the options to the header is not add in a response request, you could add the always keyword from Apache.
In my case i needed to add the access control allow origin in the response of the redirection and not in the result of the redirection.
And a redirection is giving the 302 code status so the header wasn't filled with the correct information.
In this case I needed to add it :
Header always set Access-Control-Allow-Origin "*"
For more information you can check this thread :
Apache: difference between "Header always set" and "Header set"?

Related

Internal Server Error when add Header set Access-Control-Allow-Methods to Htaccess

I would like to add an authorization to my web site through htaccess.
I added this code :
# BEGIN Cache-Control Headers
<ifmodule mod_headers.c>
Header set Access-Control-Allow-Origin: https://www.example.com
Header set Access-Control-Allow-Headers: Special-Request-Header
Header set Access-Control-Allow-Credentials: true
Header set Access-Control-Max-Age: 240
</ifmodule>
# END Cache-Control Headers
But the website give Internal Server Error when I try to add the line below :
Header set Access-Control-Allow-Methods: PUT, POST, OPTIONS
A special authorization is required or it is a syntax error ?
Try with "":
Header set Access-Control-Allow-Methods "PUT, POST, OPTIONS"

Font not loading - CORS says header contains no Access Control but there is

The problem: I am using html generated from one site that is being pushed to another site (different domains). All is working well except the font (used mainly for icons) is not showing up. I am receiving a CORS error as described further below.
I have added the following code to my .htaccess file on the site where the fonts are stored that allows fonts to be access across any domain:
<FilesMatch ".(eot|ttf|otf|woff)">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
I checked the header using cUrl:
curl -I https://mywebsite.com/fonts/flatpack.woff?tzy7cr
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 23 Jun 2017 18:33:58 GMT
Content-Type: text/plain
Content-Length: 142020
Connection: keep-alive
X-Accel-Version: 0.01
Last-Modified: Fri, 23 Jun 2017 17:49:02 GMT
ETag: "1a474c-22ac4-552a4378235b7"
Accept-Ranges: bytes
X-Powered-By: PleskLin
Access-Control-Allow-Origin: *
The Access Origin response tells me that the font should be readable but I'm still getting this error from the requesting website:
Access to Font at https://mywebsite/fonts/flatpack.woff?tzy7cr' from
origin 'http://anotherwebsite.com' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://anotherwebsite.com' is therefore not allowed
access.
Thoughts or suggestions???
Edit: Here is a live link to a test page that fails to load the icon fonts.
Almost got it right:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Methods: "GET"
You need to add the header not set. I'd also add the method to be sure.
Premium font purchased by some other website can be abused another site. That is the reason of complication at browser level coding. Image will not suffer such issue. Font related CORS is complicated by types of fonts, browsers and bugs. Unless you are using paid origin pull CDN or known font provider (free or paid), it is practical to serve font from own server for the sake of making sure that font loads on all browsers, all devices. It is worthy to read :
official W3 doc about CORS,
Mozilla doc,
MaxCDN's guide,
W3's CSS font doc,
this old bug report
this pull request
There are three options from the above resources for giving you a correct answer. You need to test from webpagetest dot org from different user agents & devices and try to watch the video of screenshot.
One :
SetEnvIf Origin "https?://(.*\.(mozilla|allizom)\.(com|org|net))" CORS=$0
Header set Access-Control-Allow-Origin %{CORS}e env=CORS
<FilesMatch "\.(ttf|woff|eot)$">
Header append vary "Origin"
ExpiresActive On
ExpiresDefault "access plus 1 year"
</FilesMatch>
Two (Single domain, HTTPS) :
<FilesMatch "\.(ttf|otf|eot|woff)$">
SetEnvIf Origin "^http(s)?://(.+\.)?anotherwebsite\.com$" AccessControlAllowOrigin=$0
Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
</FilesMatch>
Three (Multiple domains) :
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
SetEnvIf Origin "http(s)?://(www\.)?(anotherwebsite.com|cdn.anotherwebsite.com|blahblah.anotherwebsite.com)$" AccessControlAllowOrigin=$0
Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
</IfModule>
</FilesMatch>
Also make sure that proper MIME types are present :
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-opentype .otf
AddType image/svg+xml .svg
AddType application/x-font-ttf .ttf
AddType application/font-woff .woff
AddType application/font-woff2 .woff2
Make sure to run Apache configtest before restarting. You may need to activate some module.
I do not want to take credit for the answer, but this worked for me, thanks to this guy:
https://crunchify.com/how-to-fix-access-control-allow-origin-issue-for-your-https-enabled-wordpress-site-and-maxcdn/
Add below lines to .htaccess file and put it inside your (font) folder:
<ifmodule mod_headers.c="">
SetEnvIf Origin "^(.*\.domain\.com)$" ORIGIN_SUB_DOMAIN=$1
Header set Access-Control-Allow-Origin "%{ORIGIN_SUB_DOMAIN}e" env=ORIGIN_SUB_DOMAIN
Header set Access-Control-Allow-Methods: "*"
Header set Access-Control-Allow-Headers: "Origin, X-Requested-With, Content-Type, Accept, Authorization"
</ifmodule>

htaccess - How to NOT send Access Control headers when same origin

My API caters to requests from other origins, so I have set the following in .htaccess:
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Headers "Content-Type,Accept"
Header always set Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS"
Header always set Access-Control-Expose-Headers "Content-Type,Content-Length"
However, I would like for these headers to NOT show up when there is no preflight required, e.g., for GET requests, or when my own site is accessing this API.
An example:
$ curl 127.0.0.1/api/featured/ -I
HTTP/1.1 200 OK
Date: Thu, 24 Nov 2016 08:33:47 GMT
Server: Apache/2.4.18 OpenSSL/1.0.1k-fips PHP/5.6.19
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type,Accept
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Access-Control-Expose-Headers: Content-Type,Content-Length
X-Powered-By: PHP/5.6.19
Content-Type: text/html; charset=UTF-8
This feels rather extraneous; this is a curl in localhost, and it's still sending the CORS headers. How should I go about this?
Suppressing the CORS headers when the request is same-origin can be done with something like:
SetEnvIf Origin "^https://example\.com$" IS_SAME_ORIGIN
Header always set Access-Control-Allow-Origin "*" env=!IS_SAME_ORIGIN
Header always set Access-Control-Allow-Headers "Content-Type,Accept" env=!IS_SAME_ORIGIN
Header always set Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS" env=!IS_SAME_ORIGIN
Header always set Access-Control-Expose-Headers "Content-Type,Content-Length" env=!IS_SAME_ORIGIN
The SetEnvIf makes Apache check the Origin request header and set an IS_SAME_ORIGIN environment variable if the value of the Origin header is "https://example.com".
The other lines use the optional final argument of the Header directive to specify that the CORS headers are sent only if the IS_SAME_ORIGIN environment variable is not set.

Cross-Origin Resource Sharing policy Font

I am using W3 Total Cache with Amazon cloudfront. I have in my htaccess file:
# BEGIN W3TC CDN
<FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
# END W3TC CDN
But still getting error:
Font from origin 'https://example.cloudfront.net' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.example.com' is therefore not allowed access.
Why is this happening?
Found the solution in this link: https://www.naschenweng.info/2014/09/23/wordpress-w3-total-cache-cloudfront-font-cors-issue/.
You need to change the CloudFront distribution's behaviors settings:
Change “Forward Headers” from “None” to “Whitelist”
Add “Origin” to the “Whitelist Headers”
Make sure that “Use Origin Cache Headers” is checked
Then invalidate the cached fonts.
Wrestling with this for days, and think I finally fixed it. Here are some things to check:
The webserver config should add the proper header. Apache syntax is listed in the question. Here's Nginx syntax that I used:
location ~* \.(eot|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin '*';
}
Within W3TC > Performance > CDN > Custom File List, I added the following to upload the actual font files:
{plugins_dir}/*.ttf
{plugins_dir}/*.woff
While you're there, set the Theme file types to upload to the following. Per #Yao's link, the default separators are inconsistent (should all be semicolons, not commas)
*.css;*.js;*.gif;*.png;*.jpg;*.ico;*.ttf;*.otf;*.woff;*.less
In S3 > Permissions > CORS Configuration, change the default
<AllowedHeader>Authorization</AllowedHeader>
to:
<AllowedHeader>*</AllowedHeader>
You should start seeing the necessary Access-Control-Allow-Origin header in the response.
In CloudFront > Distribution > Behaviors, make the following changes:
Change Allowed HTTP Methods to GET, HEAD, OPTIONS (you need OPTIONS)
Change Forward Headers to Whitelist
Under Whitelist Headers, Add >> Origin
To test:
curl -I -s -X GET -H "Origin: www.example.com" https://abcdefg543210.cloudfront.net/wp-content/path/to/foo.ttf
This should give you back the following header:
Access-Control-Allow-Origin: *
X-Cache: Miss from cloudfront
I found this blog post to be pretty helpful:
http://blog.celingest.com/en/2014/10/02/tutorial-using-cors-with-cloudfront-and-s3/
basicly It's because the font isn't set to be shared outside of the domain that you are on, so you can just use it as a resourse for, in this case, https://example.cloudfront.net
This can be changed in the webserver settings though.
The problem may not always be with the origin settings on Nginx or Apache at your web server end.
You will also need to enable CORS on your S3 AWS account for this to work correctly.

Security issue with .htaccess

Firstly I tried adding multiple ifmodule but it does not work.
<ifModule mod_headers.c>
Header set Access-Control-Allow-Origin: http://domainurl1.com
</ifModule>
<ifModule mod_headers.c>
Header set Access-Control-Allow-Origin: http://domainurl2.com
</ifModule>
When try to add multiple ifmodule only last one(http://domainurl2.com) works others not.
then I try following code it works but i think it is not secure to allow everyone
<ifModule mod_headers.c>
Header set Access-Control-Allow-Origin: “*”
</ifModule>
I have 5 domain that i have to allow.
Are there any solutions for adding multiple domains that i want to allow?
Try this if you want a quick fix
<ifModule mod_headers.c>
Header add Access-Control-Allow-Origin "http://domainurl1.com"
Header add Access-Control-Allow-Origin "http://domainurl2.com"
</ifModule>
However, this is not the recommended solution by W3C, instead you should make the server read the Origin header from the client, then compare it to a list of allowed domains and finally send the value of the Origin header back to the client as the Access-Control-Allow-Origin header. Check http://www.w3.org/TR/cors/#access-control-allow-origin-response-hea for more details.

Resources