I actually don't know the right title for this question, because of I've found many similars but still couldn't figure the solution out.
My problem is that (on Chrome) the website I've working on remain showing console log: XMLHttpRequest cannot load http://resource.domain.com/file.css. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.my-site-url.tld' is therefore not allowed access.
I've tried to allow that resources via .htaccess files using this code.
<FilesMatch "\.(jpg|jpeg|png|gif|js|css)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin http://wp.com,http://ajax.googleapis.com,http://fonts.googleapis.com,http://zor.fyre.co
Header set Access-Control-Allow-Credentials true
</IfModule>
</FilesMatch>
Doesn't work. I've also tried php and jsonp version.
Anyone please help me to fix this issue.
Additional info:
Lately, in inspect elements > Networks > Headers section, I found this message:
Your issue most likely stems from the fact that you are trying to load content from an external domain, which is prohibited in a normal json call hence the No 'Access-Control-Allow-Origin' error. The technique you may need is known as JsonP. I would link the documentation; however, it really can depend on the javascript framework you are using. I recommending reviewing this post for a walk-through on how to invoke this behaviour via normal JS. https://stackapps.com/questions/891/how-to-call-the-api-via-jsonp-in-plain-old-javascript
Hope this helps!
Related
today I have some new warnings in chrome console:
Error with Permissions-Policy header: Unrecognized feature: 'interest-cohort'.
Error with Permissions-Policy header: Unrecognized feature: 'ch-ua-full-version-list'.
I don't want my site to be included inside this google's feature
searching the web I found the following solution (.htaccess file):
<IfModule mod_headers.c>
Header always set Permissions-Policy: interest-cohort=()
</IfModule>
but it doesn't help. The warnings are still in console
Is there an efficient way to stop appearing this messages ?
Google have stopped running the experiment and are looking at a new approach: https://blog.google/products/chrome/get-know-new-topics-api-privacy-sandbox/amp/
So you don’t need to exclude you site from it anymore (hence the error message).
Note also even when they were running that experiment, it only generated and used an error interest cohort when using Google Ads. So again I need to do anything if not running ads. And if that interested in privacy then probably not running any ads that would use this.
I see there are lots of threads about No 'Access-Control-Allow-Origin' header. My question is about how to solve this in plunker.
I have a piece of code in plunker, which tries to load an external html file. It gives an error No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://run.plnkr.co' is therefore not allowed access.
I tried to launch Chrome by open /Applications/Google\ Chrome.app --args --disable-web-security, but it did not help.
Does anyone have any workaround to make loading an external html file work in plunker?
You can use an open CORS proxy like https://cors-anywhere.herokuapp.com/.
The way it works is, instead of making your request directly to https://site.to.request you make your request to https://cors-anywhere.herokuapp.com/https://site.to.request.
The https://cors-anywhere.herokuapp.com/ proxy then adds the necessary CORS headers.
Or you can run your own instance from the source at https://github.com/Rob--W/cors-anywhere/
I'm having difficulty finding out what it means when I have the response header Non-Authoritative-Reason : HSTS
I have searched a lot but just came up with some explanations about HSTS (redirection from HTTP to HTTPS). Can anyone help me with that? By the way I'm using Chrome.
Thanks
The server you are trying to connect with uses strict-transport-security (HSTS) to ensure https only is used with this site rather than the default http.
This means if you enter http://www.servername.com then Chrome will automatically convert this to https://www.servername.com.
This is a security feature to prevent use of http, which is unencrypted and which can be read and altered by a hacker. This can be set by the server telling Chrome (via a special HTTP Header sent in response to requests) that it uses HSTS. This setting is then cached by Chrome for the given amount of time as defined in the max-age value in that header. Additionally the site owner can submit their site to a preload list that is automatically included in Chrome - which protects even the first visit as normally you need to visit the site to receive the header to activate this.
The way Chrome shows this in the network tab is by creating a dummy 307 response with a redirect to the https version of the address. But that's a fake response and is not generated by the server - the reality is Chrome did that internally before the request even went to the server.
To clear this setting for a site you can type the following into Chrome's URL field: chrome://net-internals/#hsts and then search for your site and delete it. You may also set this at a top level domain and include subdomains so you may need to delete from there. Alternatively you can just alter your server config to publish the header with a max-age of 0 and revisit the site to clear this, then stop publishing the header, which can be helpful for other browsers where it's not quite as easy to clear this.
Note you cannot clear this setting if a site is on the preload list as this is embedded in the web browser's code. The site owner can submit a request to be removed from the preload list but this takes several months to go through the release cycle for Chrome and no defined timeline for other browsers. Chrome also provides no way to override preloaded settings - for security reasons.
Some additional info to BazzaDP's answer...
The Non-Authoritative-Reason : HSTS returned in the response is not something you have configured, but rather Chrome itself. Since Chrome hijacks the request, Chrome will also add this particular header to tell HSTS is enabled. Looking at the network tab, you will see the fake 307 response with this header set.
All this is done since you included the Strict-Transport-Security header on your server.
If you want to go all in, here's the HSTS preload list
According to MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security):
The Strict-Transport-Security header is ignored by the browser when
your site is accessed using HTTP; this is because an attacker may
intercept HTTP connections and inject the header or remove it
And the HSTS Preload list deployment recommendations mention:
Add the Strict-Transport-Security header to all HTTPS responses
The HTML5 Boilerplate shows how to only set Strict-Transport-Security over HTTPS (in apache):
# Set 'Strict-Transport-Security' over HTTPS only!
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ %{ENV:PROTO}://%1%{REQUEST_URI} [R=301,L]
</IfModule>
I'm using HTML5 canvas and the .toDataURL() function through KineticJS's .toDataURL() method. The canvas uses images that my users uploaded to the site, which are stored on a different machine and subdomain farm1.domain.com.
Problem: When .toDataURL() is called, I get the error
SECURITY_ERR: DOM Exception 18
Is there a way around this? I also get the same problem if the user access the page via domain.com and the image is hosted at www.domain.com.
Attempt:
I added the following lines to httpd.conf within virtualhost and restarted the apache service.
Header add Access-Control-Allow-Origin "http://www.domain.com"
Header add Access-Control-Allow-Origin "http://domain.com"
Header add Access-Control-Allow-Origin "http://farm1.domain.com"
I still get the same error when accessing image hosted on www.domain.com from page on domain.com! Is there a way around this in KineticJS?
You will need to add the Access-Control-Allow-Origin headers to the images you are loading, not to the page which is loading them. For details on this header, and on CORS in general, you may want to read "CORS isn't just for XHR", which specifically discusses this issue.
There is no way around this error. Images loaded in a canvas from a different domain will raise this error as currently implemented by every browser. In your case the images should be stored in the same domain and you would not be getting exceptions.
I have the same problem with this post context.getImageData() on localhost?, but instead of localhost I am working on a https site so this provokes the problem with the canvas. It there a solution for this case?
These problems arise when you are trying to get data from images loaded across different domains.
One way to solve this (if you are the one in control of serving the images) is by enabling CORS (Cross-Origin Resource Sharing). What this does is basically add an Access-Control-Allow-Origin header to the served image.
You can read all about it in http://www.w3.org/TR/cors/. Your use case is described specifically in http://www.w3.org/TR/cors/#use-cases, section "Not tainting the canvas element".
There is a great resource for understanding how to enable CORS in http://enable-cors.org/. If you're running an apache instance, the easiest way is to use a .htaccess file to enable the headers.
However, if you are not in control of the served images, then you may need to ask permission to use them and probably copy them to your own server.