Как я могу исправить проблему с веб-шрифтом "Отсутствует заголовок ответа общего доступа к ресурсам (CORS)"?
Почему-то шрифты перестали отображаться на моих сайтах. Шрифты хранятся локально, на том же сервере, что и сайт.
Я посмотрел на проблему, и это, кажется, Missing Cross-Origin Resource Sharing (CORS) Response Header но я не могу понять решение для этого.
Все различные сайты говорят, чтобы использовать: Access-Control-Allow-Origin:*
Но так как я в первую очередь фронтенд, я не знаю, где его поставить. Может ли это помочь моему хозяину?
Что я могу сделать, чтобы решить проблему?
РЕДАКТИРОВАТЬ:
рассматриваемый сайт: http://cyclistinsuranceaustralia.com.au/
Например, номер телефона в правом верхнем углу должен быть шрифтом Bebas, но по умолчанию это Impact.
В консоли я получаю ошибки:
Шрифт из источника " http://www.cyclistinsuranceaustralia.com.au/" заблокирован для загрузки политикой совместного использования ресурсов перекрестного происхождения: заголовок "Access-Control-Allow-Origin" имеет значение " http://www.cyclistinsuranceaustralia.com.au/', который не равен предоставленному источнику. Поэтому происхождение ' http://cyclistinsuranceaustralia.com.au/' не разрешено.
Я связываюсь с моим хозяином, который сказал поставить:
Access-Control-Allow-Origin "http://www.cyclistinsuranceaustralia.com.au"
в моем файле.htaccess, но это не изменилось.
6 ответов
В вашем HTML вы установили "базовый" тег:
<base href="http://www.cyclistinsuranceaustralia.com.au/">
- Удалите эту строку из своего HTML, если она вам не нужна. Это должно заставить работать шрифты при просмотре с http://cyclistinsuranceaustralia.com.au/.
- Вы, вероятно, должны будете перенаправить http://www.cyclistinsuranceaustralia.com.au/ на http://cyclistinsuranceaustralia.com.au/
Если вы просто заинтересованы в использовании Access-Control-Allow-Origin:*
Вы можете сделать это с этим .htaccess файл в корне сайта.
Header set Access-Control-Allow-Origin "*"
Некоторая полезная информация здесь: http://enable-cors.org/server_apache.html
Я собираюсь предположить, что ваш хост использует C-Panel - и это, вероятно, HostGator или GoDaddy. В обоих случаях они используют C-Panel (на самом деле это делают многие хосты), чтобы максимально упростить администрирование Сервера для вас, конечного пользователя. Даже если вы проводите хостинг через кого-то другого - посмотрите, можете ли вы войти в какую-то административную панель и найти файл .htaccess, который вы можете редактировать. (Примечание: предшествующий период означает, что это "скрытый" файл / каталог).
Как только вы найдете файл htaccess, добавьте следующую строку:
Header set Access-Control-Allow-Origin "*"Просто чтобы посмотреть, работает ли это.Предупреждение: не используйте эту строку на производственном сервере
Он должен работать. Если нет, позвоните своему хосту и спросите его, почему линия не работает - они, вероятно, смогут быстро помочь вам оттуда.
- Как только у вас есть вышеупомянутая рабочая, измените
*на адрес запрашивающего доменаhttp://cyclistinsuranceaustralia.com.au/, Вы можете столкнуться с проблемой канонической адресации (включая www), и в этом случае вам может потребоваться настроить хост для перенаправления. Это другой и меньший мост, чтобы пересечь все же. Вы по крайней мере будете в правильном месте.
В вашем конкретном случае проблема, по-видимому, связана с доступом к сайту по неканонической ссылке (www.site.com против site.com).
Вместо исправления проблемы с CORS (которая может потребовать записи прокси на серверные шрифты с соответствующими заголовками CORS в зависимости от поставщика услуг), вы можете нормализовать свои URL-адреса, чтобы всегда серверное содержимое содержало канонический URL-адрес, и просто перенаправлять, если требуется страница без "www.
В качестве альтернативы вы можете загрузить шрифты на другой сервер /CDN, для которого известно, что настроены заголовки CORS, или вы можете легко это сделать.
У нас была именно эта проблема с fontawesome-webfont.woff2, который выдавал ошибку 406 на общем хосте (Cpanel). Я работал над неуловимым "доменом без cookie" для проекта Wordpress Multisite, и мои страницы "www.domain.tld" имели бы следующую ошибку (3 раза) в Chrome:
Шрифт из источника ' http://static.domain.tld/ ' заблокирован для загрузки политикой общего доступа к ресурсам разных источников: в запрашиваемом ресурсе отсутствует заголовок "Access-Control-Allow-Origin". Поэтому происхождение ' http://www.domain.tld/ ' не разрешено.
а в Firefox чуть подробнее:
загружаемый шрифт: загрузка не удалась (семейство шрифтов: "FontAwesome" стиль: нормальный вес: нормальное растяжение: нормальный индекс src:1): неверный URI или межсайтовый доступ запрещен источник: http://static.domain.tld/wp-content/themes/some-theme-here/fonts/fontawesome-webfont.woff2?v=4.7.0
font-awesome.min.css: 4: 14 Блокирован перекрестный запрос : одна и та же политика происхождения запрещает чтение удаленного ресурса по адресу http://static.domain.tld/wp-content/themes/some-theme-here/fonts/fontawesome-webfont.woff?v=4.7.0. (Причина: отсутствует заголовок CORS "Access-Control-Allow-Origin").
Я добрался до QWANT-INGING (QWANT.com = фантастический) и нашел этот пост:
Подстановочные поддомены Access-Control-Allow-Origin, порты и протоколы
Час в чате с разными сотрудниками службы поддержки Shared Host (кто-то даже не знал о F12 в браузере...), а затем ожидание ответа на билет, который был урезан после не радости во время игры с mod_security. Тем временем я попытался собрать воедино код для файла.htaccess из этого поста и заставил его безошибочно исправить ошибки 406:
<IfModule mod_headers.c>
<IfModule mod_rewrite.c>
SetEnvIf Origin "http(s)?://(.+\.)?domain\.tld(:\d{1,5})?$" CORS=$0
Header set Access-Control-Allow-Origin "%{CORS}e" env=CORS
Header merge Vary "Origin"
</IfModule>
</IfModule>
Я добавил это в начало моего.htaccess в корне сайта, и теперь у меня появился новый дядя по имени Боб. (*** конечно, замените части domain.tld на те, с которыми вы работаете...)
Моя любимая часть этого поста - это возможность RegEx ИЛИ (|) нескольких сайтов в этот "хак" CORS, выполняя:
Чтобы разрешить несколько сайтов:
SetEnvIf Origin "http(s)?://(.+\.)?(othersite\.com|mywebsite\.com)(:\d{1,5})?$" CORS=$0
Это исправление, по правде говоря, поразило меня, потому что я сталкивался с этой проблемой раньше, работая с Dev в компаниях из списка Fortune 500, которые находятся в миле от моей базы знаний Apache и не могли решить подобные проблемы, не заставляя ИТ-специалистов настраивать параметры Apache.
Это своего рода волшебная палочка, чтобы исправить все эти проблемы CDN с доменами без файлов cookie (или почти без файлов cookie, если вы используете CloudFlare...), чтобы уменьшить количество ненужного веб-трафика от файлов cookie, отправляемых только с каждым запросом изображения. быть отброшенным сервером как плохое свидание вслепую.
Супер Безопасный, Супер Элегантный. Вам это нравится: вам не нужно открывать пропускную способность ваших серверов для типов воров / горячих ссылок.
Эти 3 блестящие умы объединяют усилия для решения того, что раньше считалось неразрешимым с помощью.htaccess, из которого я собрал этот код:
@Noyo Noyo
@DaveRandom DaveRandom
@ pratap-koritala Pratap Koritala
У нас была похожая проблема с заголовками в Amazon (AWS) S3, предопределенная ошибка Post в некоторых браузерах.
смысл был сказать ведру CORS выставить заголовок <ExposeHeader>Access-Control-Allow-Origin</ExposeHeader>
подробнее в этом ответе: /questions/39780520/razreshit-ajax-get-iz-amazon-s3-access-control-allow-origin/39780537#39780537