Please explain to me the difference in CORS for background script and content script.
When I make a fetch request from the content script, the headers are:
Referrer Policy: strict-origin-when-cross-origin
origin: http://example.org
sec-fetch-mode: cors
sec-fetch-site: **cross-site**
and I get the error Access to fetch at 'https://api.blah-blah-blah' from origin 'http://example.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin'
And when I make the same request from the background script, everything is fine, the headers are:
Referrer Policy: strict-origin-when-cross-origin
origin: chrome-extension://faebbackmmlgdbgjmljofnijfdfaepbo
sec-fetch-mode: cors
sec-fetch-site: **none**
and I get the correct responce.
Are http://example.org and chrome-extension the same origin?
I use
Header set X-Frame-Options SAMEORIGIN
in .htaccess
But i would like to have 1 html page that isn't blocked when shown in iframe on other websites.....
How can i make 1 exception?
The Header directive provides an additional argument that allows you to set the header conditionally based on whether an environment variable is set or not.
You could then set an env var when this one URL is requested. And only allow the header to be set when the env var is not set.
For example:
SetEnvIf Request_URI "^/one-page-not-blocked\.html$" DO_NOT_BLOCK
Header set X-Frame-Options SAMEORIGIN env=!DO_NOT_BLOCK
The above SetEnvIf directive sets the env var DO_NOT_BLOCK to the value 1 when the regex matches the requested URL.
The env=!DO_NOT_BLOCK argument is successful when the env var is not set (denoted by the ! prefix).
This method allows you to add additional URLs to not block by simply adding more SetEnvIf directives.
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"
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>
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"?