Related question here.
Boris' answer to the above question seems to make sense, but I installed the Font Awesome files on my server and the problem remains:
I looked into the library and found that the font files are included in the install, so the argument about cross-server access to fonts doesn't seem valid. I don't mind using the BootstrapCDN, but then Boris' suggestion seems to apply, and I don't know how to send the right CORS headers. (I tried it, but it doesn't work either.) Any idea how I can fix this, either using the "Bootstrap CDN" or the "default CSS"? (see also these instructions.)
PS: IE10 shows the glyph correctly.
Did you try Bootstrap CDN?
Just include <link href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css" rel="stylesheet"> in your <head> section. Font files will be loaded automatically from CDN, too.
Checked this on Firefox and it works perfectly.
#Boris says:
Firefox only allows cross-domain linking of fonts if the server the font is on sends the right CORS headers.
So it's clear that it's CDNs duty to set the right headers, not yours. And them seem to do that correctly, because Firefox doesn't complain.
If you host fonts on your own server, keep in mind that cross-domain rule may still apply, e.g. font files places under example.com may be unaccessible from www.example.com, if www.example.com doesn't send the right headers.
Read this answer for tips about bypassing cross-sub-domain restrictions - this might help in your case.
Put in a custom CSS the following (for me it solved the problem):
#font-face
{
font-family:'FontAwesome';
src:url('./fontawesome-webfont.eot');
src:url('./fontawesome-webfont.eot?#iefix') format('embedded-opentype'),
url('./fontawesome-webfont.woff') format('woff'),
url('./fontawesome-webfont.ttf') format('truetype'),
url('./fontawesome-webfont.svg#FontAwesome') format('svg');
font-weight:normal;
font-style:normal
}
[class^="icon-"]:before,
[class*=" icon-"]:before
{
font-family:FontAwesome;
font-weight:normal;
font-style:normal;
display:inline-block;
text-decoration:inherit
}
I am having same issue, we use the fonts on router board using micro httpd.
i added Access-Control-Allow-Origin: * header but not working for me.
i found in firebug that the woff file is not returing anything in response text. the same thing if i use CDN url, everything works fine. so on local micro-httpd server need some mandatory header to configure. please tell me also the exact mime types for all fonts needed.
.ttf", "application/x-font-ttf"
.eot", "application/vnd.ms-fontobject"
.woff", "application/font-woff"
.svg", "image/svg+xml"
solution to make the fontawesome css work locally is to include the files under Fonts folder into the same directory of .html files(pages).
eg:File structure as of now where fontawesome is not working
prototype\pages\.html files
prototype\styles\font-awesome\css\font-awesome.min.css
prototype\styles\font-awesome\css\fonts\fontawesome-webfont.eot,fontawesome-webfont.woff
The issue here is that for a page loaded from a file:// URI, only files in (or below) the same directory of the filesystem are considered to be "same origin", and so putting the font in a different subtree (../font/) means it will be blocked by security policy restrictions.As Firefox disables cross-domain fonts "by default.
Instead change the file structure as below:
prototype\pages\.html files
prototype\styles\font-awesome\css\font-awesome.min.css
prototype\pages\fonts\fontawesome-webfont.eot,fontawesome-webfont.woff
place the fonts folder under pages directory which fixes the issue.Hope it helps.
some-class-name:before
{
content: attr(\f021);
}
worked for me
If you are the owner of your own server, you can add a HTTP header to deal with that problem. Problem based on cross domain policies.
example.com/font-awesome.woff
boo.example/index.htm
in that case you should add that header to example.com
Access-Control-Allow-Origin = "http://boo.example"
or
Access-Control-Allow-Origin = "*"
that will make your font file reachable from other sites or specific site.
Be sure your paths are correct. Use the fa class and the icon class like:
fa fa-envelope
and will work great..
Greetings.
Related
I'm trying to use #font-face to load two fonts, but am running into all kinds of strange issues. Some browsers will load the fonts, others won't. Same browser on desktop won't load but will on mobile. I don't know if there's something wrong with my code or my file structure or what (I used fontsquirrel's generator for the sdregular font, but not the other one).
My #font-face code is:
#font-face {
font-family: 'sdregular';
src: url('sd-regular-webfont.woff') format('woff');
}
#font-face {
font-family: 'BoereTudor';
src: url('BOERT___0.ttf') format('truetype');
}
My css styling code is:
.c9 {font-family: 'sdregular';}
.c7 {font-family: 'BoereTudor'; font-size: 1.5em;}
Here's the page link: https://universaltheosophy.com/hpb/voiceofthesilence.html
My stylesheets and fonts are located in the folder https://universaltheosophy.com/resources/
The css file utfonts.css calls the fonts using #font-face.
The css file utstyle.css contains the font-family setting for the two classes (.c7 and .c9)
.c7 is used for the text "Dedicated to the Few"; and .c9 is used for a symbol located here: https://universaltheosophy.com/hpb/voiceofthesilence.html#sdfootnote41sym
I've tried testing in Firefox (desktop and mobile), Chrome (desktop and mobile), and DuckDuckGo's Mobile Browser, with completely inconsistent results.
Any help would be much appreciated!
Ok, found the solution, which had nothing to do with my code. My site is a wordpress site, but I'm adding these few html files separate from wordpress. The attempt to load font files from these html files resulted in a "Access-Control-Allow-Origin (CORS origin)" error. The solution is adding this little snipped of code to the wordpress .htaccess file:
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
Solution came from here: https://crunchify.com/how-to-fix-access-control-allow-origin-issue-for-your-https-enabled-wordpress-site-and-maxcdn/
I just signed up for a cloudflare account and began forcing everything to https just to see how it worked, and to my surprise, all my images refused to work over https. now this is something I don't understand because the assets are all linked via:
HTML:
<img src="./images/image.jpg" />
CSS:
background-image: url(../images/image.jpg);
So I figured, I would change it up to use absolute urls with // instead of relative paths:
HTML:
<img src="//example.com/images/image.jpg" />
CSS:
background-image: url(//example.com/images/image.jpg);
this did not work either. so I decided to hard link to https:
HTML:
<img src="https://example.com/images/image.jpg" />
CSS:
background-image: url(https://example.com/images/image.jpg);
and again, not working. what happens is the images all buffer and as soon as they are fully downloaded and displayed,they disappear abruptly.
All of the images are available over https or http so I do not understand the issue here. Would appreciate a little insight into this and whether its a cloudflare specific issue or an issue with how I'm writing my code. Can anyone confirm that relative paths should call assets via whatever protocol is currently in use? ive not seen any issue with it in the past.
Thanks in advance
Odd problem.
Would appreciate a little insight into this and whether its a
cloudflare specific issue
In general, there should be no problem to do what you are asking, there's no CloudFlare issue
or an issue with how I'm writing my code.
Both of your code examples look good to me, the first perhaps preferable because it will work with both HTTP and HTTPS
<img src="//example.com/images/image.jpg" />
Have you
ruled out browser issues by testing with another browser?
cleared the CF cache?
tested with CF set to development mode?
ruled out any app related issues by testing https image loading on a plain HTML page?
tried changing the CF SSL Level (Flexible, Full, Strict)?
if still no joy, can you post a URL?
Good luck!
As it turns out this was a Cloud Flare issue. They have a feature called Rocket Loader, which compresses all your js files into one long minified JS file which was apparently causing one of my scripts to break, only when served over https. It has been raised as a bug with Cloud Flare support (as it is odd that it works over http but not https). This particular issue was with sss.js (Super Simple Slider) the solution supplied by Cloud Flare Support was to change my script tag for sss.js from:
<script type="text/javascript" src="js/sss.js"></script>
and adding data-cfasync="false" to the tag:
<script type="text/javascript" data-cfasync="false" src="js/sss.js"></script>
Apparently this extra bit of code makes Cloud Flare's Auto-Minifier and Rocket Loader ignore that particular file.
Hello i have an issue with my domain and ssl, when you enter to https://www.limitx.com.mx you can see a error with a ssl encryption, your connection is encrypted with modern cryptography, how i can solve this? i dont know how to fix this issue, i hope can help me. Bes regards guys!
You have two resources on your home page that are served over HTTP (mixed content).
Mixed Content: The page at 'https://limitx.com.mx/' was loaded over
HTTPS, but requested an insecure stylesheet
'http://fonts.googleapis.com/css?family=Roboto:400,900,300,700'. This
request has been blocked; the content must be served over HTTPS.
This is coming from the main file that is generating the HTML:
<link href='fonts.googleapis.com/css?family=Roboto:500,300'; rel='stylesheet' type='text/css'>
You'll need to change this to be
<link href='https://fonts.googleapis.com/css?family=Roboto:500,300'; rel='stylesheet' type='text/css'>
Mixed Content: The page at 'https://limitx.com.mx/' was loaded over
HTTPS, but requested an insecure image
'http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png'.
This content should also be served over HTTPS.
This is coming from https://limitx.com.mx/skin/frontend/ultimo/default/css/styles.css
.form-search .button {
...
background-image: url(http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png);
...
}
You cannot use an HTTPS version of this URL as the certificate for http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png does not match the host.
You can copy this file (buscar.png) locally, perhaps under skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/ and change the CSS to be
.form-search .button {
...
background-image: url(../images/infortis/_shared/generic-nav/buscar.png);
...
}
Well the issue is that other objects on your page are not using ssl, do you have any embeded links that have http instead of say https? I would check those images, they are most likely the culprit. Instead of using relative paths try hardcoding all the images with https://url to image/ alright? That should fix ya up good. Nice site btw.
For your Firefox issues: https://support.mozilla.org/en-US/questions/967766
The only way for websites to "supply ownership information" would be through a secure connection and an "Extended Validation Certificate" which will cost a few hundred USD and upwards per year at the relevant certificate authorities: https://en.wikipedia.org/wiki/Extended_Validation_Certificate
Google Issues: https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1
Your connection to the site is encrypted, but Google Chrome has detected mixed content on the page. Be careful if you're entering information on this page. Mixed content can provide a loophole for someone to manipulate the page. This content could be third- party images or ads embedded on the page.
Internet Explorer.....doesnt see any issues at all.
I'm using bootstrap and I added font awesome through Less, overriding the Glyphicons. The icons display OK in chrome but in Firefox i just see boxes.
This is how my directory looks like
-- Project
-- js
-- css
-- less
-- font-awesome
-- css
-- font
-- less
All I've modified in the Project > less > boostrap.less file has been:
#import "sprites.less";
//for this line
#import "../font-awesome/less/font-awesome.less";
As I said in Chrome works fine but for some reason Firefox shows only boxes.
Custom web fonts via CDN (or any cross-domain font request) doesn't work in Firefox or Internet Explorer (correctly so, by spec) though they do work (incorrectly so) in Webkit-based browsers.
You can fix this by adding headers to your page.
Apache
<FilesMatch ".(eot|ttf|otf|woff)">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
Nginx
if ($filename ~* ^.*?\.(eot)|(ttf)|(woff)$){
add_header Access-Control-Allow-Origin *;
}
Credit: http://davidwalsh.name/cdn-fonts
If you want a quick and easy way to make Font-awesome work, try using CDNJS. It's free and powered by CloudFlare. CORS is supported out of the box.
Try something like this:
<link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/3.2.1/css/font-awesome.min.css" media="all" rel="stylesheet" type="text/css">
If you are hosting the font on S3, you have to enable CORS on the bucket. Through AWS Management Console, edit the properties for the bucket and under Permissions click on "Add CORS Configuration". In my case, if I left the default config, it still didn't work, so I changed it to:
<CORSConfiguration>
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
</CORSRule>
</CORSConfiguration>
I was having issue with the if statement because I didn't have a $filename variable.
But I did have similar results using:
location ~ /\.(eot|otf|ttf|woff)$ {
add_header Access-Control-Allow-Origin *;
}
Using a CDN as premjg suggested is the least invasive method besides hosting it yourself. The latest version of fontawesome suggests bootstrapcdn, e.g.,
<link href="//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css" rel="stylesheet">
As a minor note, noscript silently blocks requests to the CDN unless whitelisted, and it won't prompt you to whitelist the CDN unless your page also requests JS files from the same domain.
If you're like me, modifying a web.config file is something you're not allowed to touch.
Try storing all the font files (.eot, .ttf, etc) into their own local folder, and link to them locally instead of the FontAwesome CDN. Cleared it up in IE and FF for me every time.
#font-face{ font-family:'FontAwesome'; src:url('../_fonts/fontawesome-webfont.eot'); }
If you're using wordpress and you think you've tried everything, look and see if you ever installed a Font Awesome plugin. Disable the plugin and refresh in Firefox.
This was the solution for me - the plugin's older version of font-awesome was overriding the files I was trying to update myself manually.
In fonts folder please upload the following files
FontAwesome.otf
fontawesome-webfont.eot
fontawesome-webfont.svg
fontawesome-webfont.ttf
fontawesome-webfont.woff
------------------ Important glyphicons files----------------
glyphicons-halflings-regular.eot
glyphicons-halflings-regular.svg
glyphicons-halflings-regular.ttf
glyphicons-halflings-regular.woff
Please upload the following files and after that you link your font-awesome.min.css in your header file.
Here is the following link with proper files:
http://goo.gl/WICQAf
any ideas? here's what I'm using:
#font-face {
font-family: 'Jott';
src: url(http://stuff.saikonet.org/fonts/jott/JottFLF-Bold.ttf) format('truetype');
}
Same-origin rule: By default, Firefox will only accept relative links. If you want to use absolute links or include fonts from different domains, you need to send these fonts with Access Control Headers. See: http://webfonts.info/wiki/index.php?title=%40font-face_support_in_Firefox
Can that be your problem:
In Gecko, web fonts are subject to the same domain restriction (font files must be on the same domain as the page using them), unless HTTP access controls are used to relax this restriction.
https://developer.mozilla.org/en/css/#font-face
When I downloaded the TTF it was working in Firefox as well.