Nicht in Dokumente und Webseiten geladene Schriftarten
Die meisten Webbrowser erlauben keine domänenübergreifenden Anforderungen. Dies liegt an derselben Ursprungssicherheitsrichtlinie. Das Ergebnis ist, dass bei Verwendung von Web-Schriftarten aus einer anderen Domäne manchmal Fehler auftreten können und die Schrift nicht auf der Webseite (oder in HireHop-Dokumenten) geladen wird. Grundsätzlich werden aus Sicherheitsgründen einige Dateien als „nicht kennzeichnungspflichtig“ für verschiedene Domänen vom Server, auf dem sie gehostet werden, „markiert“, sodass der folgende typische Code möglicherweise nicht funktioniert:
<style type="text/css"> @font-face { font-family: "OpenSans"; src: url("https://my_server.com/fonts/OpenSans.woff2") format("woff2"); } html, body{ font: normal 16px OpenSans, sans-serif; } </style>
Die Lösung
Um Ursprungsübergreifende Einschränkungen für Ihre Schriftarten festzulegen, muss die Antwort vom Remoteserver, auf dem die Schriftdateien gehostet werden, den Header Access-Control-Allow-Origin in der Schriftartdatei enthalten.
Wenn Sie Schriftarten wie Typekit oder Google Fonts oder Content-Delivery-Netzwerke wie BootstrapCDN, CdnJS oder JsDelivr verwenden, um Ihre bevorzugten Schriftarten zu laden, müssen Sie nichts tun, da der Header Access-Control-Allow-Origin lautet bereits in ihrem Antwortheader gesendet.
Apache
Fügen Sie zum Konfigurieren eines Apache-Webservers den folgenden Code in die Datei httpd.conf
oder .htaccess
ein.
- Fügen Sie die MIME-Header in Apache hinzu:
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
- Aktivieren Sie CORS (Cross-Origin Resource Sharing) in Apache für die MIME-Typen:
<IfModule mod_headers.c> <FilesMatch ".(eot|otf|svg|ttf|woff|woff2?)$"> Header set Access-Control-Allow-Origin "*" </FilesMatch> </IfModule>
NGINX
Fügen Sie zum Konfigurieren eines NGINX-Webservers den folgenden Code in die Datei /etc/nginx/nginx.conf
oder in Ihre benutzerdefinierte Datei /etc/nginx/conf.d/custom.conf
ein.
- Fügen Sie die MIME-Header unter NGINX hinzu:
application/vnd.ms-fontobject eot; application/x-font-opentype otf; image/svg+xml svg; application/x-font-ttf ttf; application/font-woff woff; application/font-woff2 woff2;
- Aktivieren Sie CORS (Cross-Origin Resource Sharing) unter NGINX für die MIME-Typen:
location ~* .(eot|otf|svg|ttf|woff|woff2)$ { add_header Access-Control-Allow-Origin *; }
IIS
Fügen Sie zum Konfigurieren von Microsoft IIS den folgenden Code zum Block web.config
system.webServer hinzu.
- Aktivieren Sie CORS (Cross-Origin Resource Sharing) in IIS
<system.webServer> <httpProtocol> <customHeaders> <add name="access-control-allow-origin" value="*" /> <add name="access-control-allow-headers" value="content-type" /> </customHeaders> </httpProtocol> </system.webServer>
PHP
Wenn Sie die Servereinstellungen nicht ändern können, können Sie jederzeit PHP verwenden, um die Schriftartdatei bereitzustellen.
- Verwenden Sie eine Server-Skriptdatei anstelle einer physischen Schriftartdatei
<style type="text/css"> @font-face { font-family: 'OpenSans'; src: url('https://my_server.com/fonts/OpenSans.php') format('woff2'); } html, body{ font: normal 16px OpenSans, sans-serif; } </style>
- So beheben Sie domänenübergreifende @ font-face-Probleme mit PHP beim Erstellen der folgenden Datei und nennen sie „OpenSans.php“.
<?php // fonts.php header('Access-Control-Allow-Origin: *'); header('Content-Type: application/font-woff2'); echo @file_get_contents('/fonts/OpenSans.woff2'); ?>