いくつかのウェブサイトで、Google Chromeにフォントの素晴らしいアイコンが表示されていないことに気付きました。コンソールには次のエラーが表示されます。
Origin ' http://cdn.keywest.life 'からのフォントは、クロスオリジンリソース共有ポリシーによってロードがブロックされました:要求された 'Access-Control-Allow-Origin'ヘッダーはありません資源。したがって、オリジン ' http://www.keywest.life 'はアクセスを許可されていません。
他のいくつかのサイトでもまったく同じ問題が見つかりました。これは、独自のCDN参照を次のように置き換えることで簡単に修正できます。
//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css
-ただし、これは解決策ではなく、単なる回避策です。理由と正しい解決策を知りたいです。
(原因はこれです:ウェブサイトは、MaxCDNが提供する独自のCDNを使用しており、フォントawesomeフォントへの参照を持ち、Bootstrapcdnリソースから同じリソースをロードする場合、これらはChromeによってロードされません-上記作品)
ここに問題のn例があります(メニューとフッターのソーシャルアイコン: http://www.keywestnight.com/fantasy-fest )
ヘルプ/説明をありがとう!
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>
問題はCSSファイルではなく、フォントファイルの提供方法に関係しています。 font-awesome.min.css
ファイルには次のような行があります
@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}
これにより、ブラウザはCSSファイルと同じサーバーから適切なフォントファイル(eot、woff、ttfまたはsvg)を要求します。これは論理的で正しいことです。
ただし、ブラウザがcdn.keywest.life
からそのフォントファイルを要求すると、Access-Control-Allow-Origin
ヘッダーのヘッダーを読み取って見つからないため、そのエラーメッセージが表示されます。 (これは、CSSファイルと同じサーバーからのものであるため、ブラウザのバグのようです)。
代わりに、maxcdn.bootstrapcdn.com
を使用すると、応答にAccess-Control-Allow-Origin:*
ヘッダーが含まれ、ブラウザーはこのフォントファイルを受け入れます。 cdnサーバーにこのヘッダーが含まれている場合、それも機能します。
Apacheサーバーがある場合は、この回答を参照してください: Font-awesomeがFirefoxで正しく表示されない/ CDNを介して販売する方法
フォントの素晴らしいアセットにアクセスするというこの問題は、問題に対する包括的な説明と解決策を持たない多くの人々にとって問題でした。
CORSとは:
クロスオリジンリソース共有(CORS)は、追加のHTTPヘッダーを使用して、ユーザーエージェントが現在使用中のサイトとは異なるオリジン(ドメイン)上のサーバーから選択されたリソースにアクセスする許可を得るメカニズムです。ユーザーエージェントは、現在のドキュメントの発信元とは異なるドメイン、プロトコル、またはポートからリソースを要求すると、クロスオリジンHTTP要求を作成します。
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
問題:
この問題は、フォントが素晴らしいフォントがどのようにロードされるかに起因します。
@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
}
フォントは、スタイルシート(CSS)を介してロードされます。ここにある状況は次のとおりです。
解決策:
ファイルストレージにCORSルールが作成されている間S3、およびリソースへのアクセスが問題のドメインに与えられました。CDNがCSSで指定されたフォントをロードしようとすると、これらのフォントのロード時に指定されたオリジン/ドメインはCDNのものですが、CORSアクセスはCDNに与えられていませんドメイン。
CDNドメインのCORSルールを作成します。
応答を変更できないCDNを使用しているため、font-awesome.min.css
を変更し、相対パスを絶対パスに置き換えて機能しました。
答えはどれもうまくいきませんでした。maxcndバックオフィスでEdgeルールを作成する必要がありました(ゾーンの設定ファイルを変更します)
詳細はこちら
https://www.maxcdn.com/one/tutorial/Edge-rules-recipes/https://www.maxcdn.com/one/tutorial/create-a-rule /