just noticed on several websites that the font awesome icons aren's showing in Google Chrome. The console shows the following error:
Font from origin 'http://cdn.keywest.life' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://www.keywest.life' is therefore not
allowed access.
I found the exact same issue on several other sites. This can be easily fixed by replacing the own CDN reference with:
//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css
-however, this is not the solution, just a workaround. I would love to know the reason and the right solution.
(the cause is this: the website is using it's own CDN, provided by MaxCDN and has the reference to the font awesome fonts and these are not loaded by Chrome, if you are loading the same resource from the Bootstrapcdn resource -mentioned above- it works)
here is a n example of the issue (in the menu and the social icons in footer: http://www.keywestnight.com/fantasy-fest )
Thanks for any help/explanatioon!
Here is the working method to allow access from all domains for webfonts:
# Allow access from all domains for webfonts.
# Alternatively you could only whitelist your
# subdomains like "subdomain.example.com".
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
The problem isn't with the CSS file, it has to do with how the font file is served. The font-awesome.min.css file has lines like
#font-face{font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0')
format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0')
format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0')
format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal}
which cause the browser to request an appropriate font file (eot, woff, ttf or svg) from the same server as the CSS file. This is logical and correct.
However, when the browser requests that font file from cdn.keywest.life, it reads the headers for a Access-Control-Allow-Origin header and doesn't find one so it gives that error message. (This seems like a browser bug to me because it's coming from the same server as the CSS file).
Instead, when you use maxcdn.bootstrapcdn.com the response includes the Access-Control-Allow-Origin:* header and the browser accepts this font file. If your cdn server included this header then it would work too.
If you have an Apache server, see this answer: Font-awesome not properly displaying on Firefox / how to vend via CDN?
This issue of accessing font-awesome assets has been a problem for many people without a comprehensive explanation and resolution to the problem.
What is CORS:
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use. A user agent makes a cross-origin HTTP request when it requests a resource from a different domain, protocol, or port than the one from which the current document originated.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
The Problem:
The problem stems from how the font-awesome fonts are loaded.
#font-face{
font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0') format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0') format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0') format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal
}
The fonts are loaded via the stylesheet (CSS). The situation we have here is:
The Solution:
While CORS rules have been created on your file storage e.g. S3, and access to the resource has been given to the domain in question, when CDN tries to load the fonts specified in the CSS the origin/domain specified when loading these fonts is that of the CDN but no CORS access has given to the CDN domain.
Create a CORS rule for the CDN domain.
I use a CDN that doesn't allow me to modify its response, so I modified font-awesome.min.css, replacing relative path with absolute path and it worked.
None of the answers worked for me, I had to create an edge rule on maxcnd back office (which change config file on you zone)
More info here
https://www.maxcdn.com/one/tutorial/edge-rules-recipes/
https://www.maxcdn.com/one/tutorial/create-a-rule/
The solution to this is to use another cdn for fontawesome.
https://www.cdnpkg.com/font-awesome/5.11.0
If you're like me and using the official WordPress Font Awesome plugin, you'll want to go into settings and switch from "Use a CDN" to "Use a Kit".
Related
I am unable to load a font file for my WordPress website. This happens specifically in Chrome browsers, Safari and others don't seem to share this issue.
The font files are located on the same folder where the rest of the assets and public files are contained. These load without any problem, images, css, javascript etc. Only font files seem to cause this problem.
The console shows the following error:
Access to font at 'https://example.com/wp-content/uploads/2019/08/font-file.otf' from origin 'https://www.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
As stated before, in other browsers, like Safari, the fonts load with no problem. I would like to solve this issue so it works across all browsers.
Check wordPress address and site address in your blog Settings > General settings.
Here whole answer:
https://wordpress.stackexchange.com/questions/278512/access-to-font-not-allowed-by-cors-policy
I am having a problem with font embedding with CSS. I only have very few experiences with front end. Now I am about to deploy my website. But before I deploy it, first I uploaded all asset files like js,css and fonts to my CDN server. But my website is still on localhost. Then I changed all the asset link to my cdn link and I accessed my website on localhost. All javascript files on CDN are working perfectly with my local website. CSS files are also working fine except font embedding.
I am embedding font like this before I change links to CDN.
#font-face {
font-family: 'TharLon';
src: url(../fonts/tharlon.woff) format('woff');
}
.font-class{
font-family:'TharLon' !important;
}
It is working perfectly when all are on localhost.
Then I changed all links to CDN and embedded font like this
#font-face {
font-family: 'TharLon';
src: url('http://d3ewfjbf99d22n.cloudfront.net/assets/fonts/tharlon.woff') format('woff');
}
.font-class{
font-family:'TharLon' !important;
}
When I do this, font embedding is not
This is most likely because of CORS.
As you seem to be using an Amazon S3, you can add the required headers as follows:
Login to your Amazon account.
Choose your S3 Bucket
Click on Edit CORS Configuration
Add following code and save all settings
<CORSConfiguration>
<CORSRule>
<AllowedOrigin>http://www.example1.com</AllowedOrigin>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>DELETE</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
From: https://www.maxcdn.com/one/tutorial/how-to-use-cdn-with-webfonts/ (scroll down to S3 bucket)
It would appear your have a problem with CORS.
I just added this to a JSFiddle and I got this error:
Font from origin 'https://d3ewfjbf99d22n.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://fiddle.jshell.net' is therefore not allowed access.
You have to be sure that your CDN accepts the OPTIONS method used by some browsers before get an endpoint.
In CloudFront (AWS) only GET and HEAD methods are accepted by default
I recently applied an SSL certificate to my domain, but I'm having problems with some of the styles when viewing my website on HTTP:// the styles are fine. But, when viewing it through HTTPS:// no styles are applied at all.
I found out what the problem was. I wasn't loading my third party styles through HTTPS. I switched to HTTPS, and all problems were solved.
You're probably using an http:// link to a stylesheet on an https:// website.
Secure websites are not allowed to mix protocols. Everything has to be embedded from a secure server. Browsers will ignore/block HTTP resources on HTTPS pages (with varying degree of strictness).
The reason for this blocking is that insecure HTTP resources like stylesheets and scripts could still be modified by an attacker and used to spoof/hijack secure parts of the site.
If the stylesheet is served from your server, then omit protocol+host part of the URL, i.e. instead of http://example.com/style.css use /style.css as the URL, so it'll work on both HTTP and HTTPS. You can also use protocol-relative URLs.
If you have to have one full URL, then use https://… URLs only.
If the requested URI is https, if you have resources on the page (images, stylesheets, JavaScript files et. al.) that are requested with the http scheme some browsers may block them because they are considered insecure. You can circumvent that per-browser, but you also have alternatives in your code:
Use https to request everything, or at least match the schems.
Use // to indicate the scheme. The browser will match the scheme with the request URI. For example: <link rel="stylesheet" type="text/css" href="//example.com/path/to.css">
I have a wordpress site here http://itrain.com.my/v3/ as my Home Page
I am wondering why it is not displaying well in Firefox?
Anyone who is good in css?
By the way, try to look at the subpages http://www.itrain.com.my/v3/index.php/about-us/
it display well.
I am really wondering why does it happening.
Any can help me? Any suggestion, recommendations?
I think problem is with URL.
It work http://www.itrain.com.my/v3/ but doesnt work on http://itrain.com.my/v3/
Set on your server redirection (301) from non-www URL to www URL.
I would wager you have the font installed on your local machine. I don't see it on any browser. Instead, I get two 404 errors.
In other words: please make sure the font files are available at the locations their respective locations: http://www.itrain.com.my/v3/wp-content/themes/itrain/img/fonts/big_noodle_titling-webfont.woff and http://www.itrain.com.my/v3/wp-content/themes/itrain/img/fonts/bebas__-webfont.woff.
[EDIT]
I've just looked at the fonts directory listing on your site. The ttf and eot versionf of your fonts are available, the woff and svg are listed, but result in a 404 error. Furthermore, the ttf version (downloaded instead of woff in Firefox, after getting a 404) seems to generate an empty HTTP response.
So... Make sure the fonts are there, make sure they have proper privileges set (like 0644). I can't see any other issues than the font files themselves as the CSS appears to be correct.
[EDIT 2]
#kubedan provides a great tip that seems to fit your concern about the htaccess: the domain the fonts are downloaded from is always preceded with www. Firefox will refuse to download such content, you need to use the same domain.
I'm reading through details on HTML5's app cache manifest (especially from this excellent article). I'm curious if this idea would work:
We host all of our static resources (scripts, css, fonts, images) on a CDN within a subdomain (e.g. cdn.example.com and app is on www.example.com). Is it possible to host the app cache manifest on the CDN as well? For example,
<!doctype html>
<html manifest="http://cdn.example.com/appcache.manifest">
...
<script src="http://cdn.example.com/foo.js"></script>
...
</html>
If yes, can the manifest listings be from the CDN root? For example, in the manifest:
CACHE MANIFEST
/foo.js
Does anyone have any experience with this and/or know of any caveats?
EDIT: The working draft of the WHATWG spec it says "Offline application cache manifests can use absolute paths or even absolute URLs" and then shows an example with CDN URLs for images.
I tested with my manifest (in real example)
CACHE MANIFEST
# 2010-06-20:v1
iscroll.js
http://peach.blender.org/wp-content/uploads/big_big_buck_bunny.jpg
It works to me... You can check you manifest with validator http://manifest-validator.com/.
W3C only says the document (HTML file that have manifest attribute) must be same origin source with the manifest, they don't tell URL of resources must be too... You should read it carefully (at here). I also found the cross-site URL in W3 example (check here), that means it works correctly...
Finally, DON'T TRY TO PUT MANIFEST FILES ON CDN, JUST PUT IT IN YOUR SERVER AND LINK RESOURCE TO CDN. Manifest files have to have the same origin as their master entries, which includes their HTML files, and the browser checks the manifest file to see if its list of HTML pages has changed, rather than checking your HTML page to see if it points to a different manifest file.
The cached contents must satisfy the same origin restriction and the origin for comparison is determined by the calling page (the HTML page). If all of the resources you are trying to cache have a different host name then according to the spec they should be rejected. So even if you could specify the manifest to be on the cdn and not your main host, the caching should fail.