Access control allow origin несколько доменов

Access-Control-Allow-Origin Несколько доменов происхождения?

Есть ли способ разрешить несколько кросс-доменов, используя заголовок Access-Control-Allow-Origin ?

Я знаю о * , но он слишком открыт. Я действительно хочу разрешить только пару доменов.

Как пример, что-то вроде этого:

Я пробовал приведенный выше код, но он не работает в Firefox.

Можно ли указать несколько доменов или я застрял только на одном?

Похоже, рекомендуемый способ сделать это — заставить ваш сервер читать заголовок Origin с клиента, сравнить его со списком доменов, которые вы хотели бы разрешить, и, если он совпадает, передать значение заголовка Origin обратно клиенту в качестве заголовка Access-Control-Allow-Origin в ответе.

С .htaccess вы можете сделать это так:

Другое решение, которое я использую в PHP:

Это сработало для меня:

Когда положите в .htaccess , он будет работать наверняка.

У меня была та же проблема с woff-шрифтами, у нескольких поддоменов был доступ. Чтобы разрешить субдомены, я добавил что-то вроде этого в httpd.conf:

Для нескольких доменов вы можете просто изменить регулярное выражение в SetEnvIf .

Здесь, как повторить заголовок Origin, если он соответствует вашему домену с помощью Nginx, это полезно, если вы хотите обслуживать несколько поддоменов шрифта:

Вот что я сделал для приложения PHP, которое запрашивает AJAX

Если запрашивающий источник разрешен моим сервером, верните сам $http_origin качестве значения заголовка Access-Control-Allow-Origin вместо возврата символа подстановки * .

Есть один недостаток, о котором вам следует знать: как только вы выберете исходные файлы на CDN (или на любой другой сервер, который не позволяет создавать сценарии), или если ваши файлы кэшированы на прокси-сервере, изменение ответа на основе Заголовок запроса «Origin» не будет работать.

Для нескольких доменов в вашем .htaccess :

Для пользователей Nginx разрешить CORS для нескольких доменов. Мне нравится пример @marshall, хотя его антверпы соответствуют только одному домену. Для соответствия списку домена и поддомена это регулярное выражение облегчает работу со шрифтами:

Это будет отражать только заголовки «Access-Control-Allow-Origin», которые соответствуют указанному списку доменов.

Для IIS 7.5+ с установленным модулем URL Rewrite 2.0 см. этот ответ SO

Вот решение для веб-приложения Java, основанное на ответе yesthatguy.

Я использую Джерси REST 1.x

Сконфигурируйте web.xml, чтобы знать о REST Джерси и CORSResponseFilter

Вот код для CORSResponseFilter

Как упомянуто выше, Access-Control-Allow-Origin должен быть уникальным, а Vary должен быть установлен на Origin если вы находитесь за CDN (Content Delivery Network).

Соответствующая часть моей конфигурации Nginx:

Возможно, я ошибаюсь, но насколько я вижу, Access-Control-Allow-Origin имеет «origin-list» качестве параметра.

И из этого я утверждаю, что допускается различное происхождение, и оно должно быть разделено пробелами

Я изо всех сил пытался настроить это для домена, использующего HTTPS, поэтому я решил, что смогу поделиться решением. Я использовал следующую директиву в файле httpd.conf:

Измените example.com на свое доменное имя. Добавьте это внутри в свой файл httpd.conf. Обратите внимание, что если ваш VirtualHost имеет суффикс порта (например, :80 ), эта директива не будет применяться к HTTPS, поэтому вам также нужно перейти в /etc/apache 2/sites-available/default-ssl и добавить тот же директивы в этом файле, внутри раздела .

После обновления файлов конфигурации вам необходимо будет выполнить следующие команды в терминале:

Если у вас возникли проблемы со шрифтами, используйте:

Для приложений ExpressJS вы можете использовать:

HTTP_ORIGIN не используется всеми браузерами. Насколько безопасен HTTP_ORIGIN? Для меня это пустое в FF.
У меня есть сайты, на которых я разрешаю доступ к моему сайту для отправки по идентификатору сайта, затем я проверяю свою БД для записи с этим идентификатором и получаю значение столбца SITE_URL (www.yoursite.com).

Даже если отправка по допустимому идентификатору сайта требует запроса из домена, указанного в моей БД, связанной с этим идентификатором сайта.

Пример кода PHP для сопоставления поддоменов.

Здесь представлен расширенный вариант для apache, который включает в себя некоторые из последних и запланированных определений шрифтов:

И еще один ответ в Django. Чтобы иметь один вид, разрешающий CORS из нескольких доменов, вот мой код:

Чтобы облегчить многодоменный доступ для службы ASMX, я создал эту функцию в файле global.asax:

Это также позволяет CORS обрабатывать глагол OPTIONS .

Для довольно простого копирования/вставки для приложений .NET я написал это, чтобы включить CORS из файла global.asax. Этот код следует советам, данным в принятом в настоящее время ответе, отражая происхождение, указанное в запросе в ответе. Это эффективно достигает «*» без его использования. Причина этого заключается в том, что он включает несколько других функций CORS, включая возможность отправки AJAX XMLHttpRequest с атрибутом withCredentials, установленным в значение true.

Более гибкий подход заключается в использовании выражений Apache 2.4. Вы можете сопоставить домены, пути и практически все остальные переменные запроса. Хотя ответ * для всех, единственными, кто его получает, являются те, кто в любом случае отвечает требованиям.

Ответ службы поддержки Google на показ объявлений через SSL и грамматика в Сам RFC, похоже, указывает на то, что вы можете разграничить URL-адреса. Не уверен, насколько хорошо это поддерживается в разных браузерах.

Если вы попробуете так много примеров кода, как я, чтобы заставить его работать с помощью CORS, стоит упомянуть, что вам нужно сначала очистить кеш, чтобы попробовать, если он действительно работает, похожий на проблемы, например, когда старые изображения все еще присутствуют, даже если он удален на сервере (потому что он все еще сохраняется в вашем кеше).

Например, CTRL + SHIFT + DEL в Google Chrome для удаления кеша.

Это помогло мне использовать этот код, попробовав множество чистых решений .htaccess , и это казалось единственным работающим (по крайней мере для меня):

Также обратите внимание, что широко распространено множество решений, которые вы должны ввести Header set . , но это Header add . . Надеюсь, что это помогает кому-то, испытывающему те же проблемы в течение нескольких часов, как я.

Ниже ответ специфичен для С#, но концепция должна быть применима ко всем различным платформам.

Чтобы разрешить перекрестные исходные запросы от веб-API, необходимо разрешить запросы Option для своего приложения и добавить примечание ниже на уровне контроллера.

[EnableCors (UrlString, Header, Method)] Теперь происхождение можно передавать только в виде строки. Поэтому, если вы хотите передать более одного URL-адреса в запросе, передайте его как разделенное запятыми значение.

Для заголовка Access-Control-Allow-Origin можно указать только один источник. Но вы можете установить источник в вашем ответе в соответствии с запросом. Также не забудьте установить заголовок Vary. В PHP я бы сделал следующее:

Читать еще: Макросы в access 2020 примеры

Мы также можем установить это в файле Global.asax для приложения Asp.net.

Ответ, похоже, заключается в использовании заголовка более одного раза. То есть вместо отправки

В Apache вы можете сделать это в разделе httpd.conf или в файле .htaccess используя mod_headers и следующий синтаксис:

Хитрость заключается в том, чтобы использовать в качестве первого аргумента add а не append .

Access-Control-Allow-Origin Несколько Доменов Происхождения?

есть ли способ разрешить несколько кросс-доменов с помощью Access-Control-Allow-Origin заголовок?

Я в курсе * , но это слишком открыто. Я действительно хочу разрешить только пару доменов.

в качестве примера, что-то вроде этого:

Я пробовал выше код, но не работает в Firefox.

можно ли указать несколько доменов, или я застрял с одним?

26 ответов:

похоже, что рекомендуемый способ сделать это — заставить ваш сервер прочитать заголовок Origin от клиента, сравнить его со списком доменов, которые вы хотели бы разрешить, и если он соответствует, Эхо-значение Origin заголовок обратно к клиенту как Access-Control-Allow-Origin заголовок в ответе.

С .htaccess вы можете сделать это так:

другое решение, которое я использую в PHP:

это сработало для меня:

во .htaccess , это будет работать наверняка.

у меня была такая же проблема с WOFF-шрифтов, неограниченное количество поддоменов, имел доступ. Чтобы поддомены я добавил что-то вроде этого в моем файле httpd.conf:

для нескольких доменов Вы можете просто изменить регулярное выражение в SetEnvIf .

вот как повторить заголовок Origin, если он соответствует вашему домену с Nginx, это полезно, если вы хотите обслуживать шрифт нескольких поддоменов:

вот что я сделал для PHP-приложения, которое запрашивается AJAX

если запрашивающий источник разрешен моим сервером, верните $http_origin сам как значение Access-Control-Allow-Origin заголовок вместо возврата * символ.

есть один недостаток, о котором вы должны знать: как только вы отправляете исходные файлы на CDN (или любой другой сервер, который не позволяет создавать сценарии) или если ваши файлы кэшируются на прокси-сервере, изменение ответа на основе заголовка запроса «Origin» не будет работать.

для нескольких доменов, в .htaccess :

для IIS 7.5+ с установленным модулем перезаписи URL 2.0 см. это так ответ

для пользователей Nginx разрешить CORS для нескольких доменов. Мне нравится пример @marshall, хотя его anwers соответствует только одному домену. Чтобы соответствовать списку домена и поддомена это регулярное выражение облегчает работу со шрифтами:

это будет только эхо заголовков» Access-Control-Allow-Origin», которые соответствуют заданному списку доменов.

вот решение для Java web app, основанное на ответе от yesthatguy.

Я использую Джерси REST 1.x

настройки сети.xml, чтобы быть в курсе Джерси REST и CORSResponseFilter

вот код для CORSResponseFilter

как уже упоминалось выше, Access-Control-Allow-Origin должен быть уникальным и Vary должно быть установлено в Origin Если вы находитесь за CDN (сеть доставки контента).

соответствующая часть моей конфигурации Nginx:

может я и ошибаюсь, но насколько я вижу Access-Control-Allow-Origin есть «origin-list» в качестве параметра.

By определение an origin-list — это:

и из этого, я утверждаю, что различные истоки признаются и должны быть пробел.

Я изо всех сил пытался настроить это для домена под управлением HTTPS, поэтому я решил, что поделюсь решением. Я использовал следующую директиву в моем httpd.conf file:

изменить example.com к Вашему доменному имени. Добавьте это внутрь в своем httpd.conf. Обратите внимание, что если ваш VirtualHost имеет суффикс порта (например :80 ) тогда эта директива не будет применяться к HTTPS, поэтому вам также нужно будет перейти к /etc / apache2 / sites-available / default-ssl и добавить ту же директиву в этот файл, внутри .

после обновления конфигурационных файлов, вам нужно будет выполнить следующие команды в терминале:

Если у вас возникли проблемы со шрифтами, использовать:

HTTP_ORIGIN используется не всеми браузерами. насколько безопасен HTTP_ORIGIN? для меня он приходит пустой в FF.
У меня есть сайты, которые я разрешаю доступ к моему сайту отправить по идентификатору сайта, Затем я проверяю свою БД для записи с этим идентификатором и получаю значение столбца SITE_URL (www.yoursite.com).

даже если отправить действительный идентификатор сайта запрос должен быть из домена, указанного в моей БД, связанной с этим идентификатором сайта.

вот расширенный вариант для apache, который включает в себя некоторые из последних и запланированных определений шрифтов:

и еще один ответ на Django. Чтобы иметь один вид разрешить CORS из нескольких доменов, вот мой код:

чтобы облегчить доступ к нескольким доменам для службы ASMX, я создал эту функцию в глобальном масштабе.файл asax:

Это позволяет обрабатывать CORS OPTIONS глагол тоже.

ответ поддержки Google на показ рекламы через SSL и грамматика в самом RFC казалось бы, указывает на то, что вы можете разделять URL-адреса пробелом. Не уверен, насколько хорошо поддерживается это в разных браузерах.

если вы попробуете так много примеров кода, как я, чтобы заставить его работать с помощью CORS, стоит упомянуть, что вы должны сначала очистить свой кэш, чтобы попробовать, если он действительно работает, подобно таким проблемам, как когда старые изображения все еще присутствуют, даже если он удален на сервере (потому что он все еще сохраняется в вашем кэше).

CTRL + SHIFT + DEL в Google Chrome, чтобы удалить кэш.

это помогло мне использовать этот код после попытки многих чистых .htaccess решения и это казалось единственным работающим (по крайней мере для меня):

Также обратите внимание, что это широко распространено, что многие решения говорят, что вы должны ввести Header set . но это Header add . . Надеюсь, это поможет кому-то, кто имеет те же проблемы в течение нескольких часов, как я.

для довольно простого копирования / вставки для приложений .NET я написал это, чтобы включить CORS из глобального.файл asax. Этот код следует рекомендациям, приведенным в принятом в настоящее время ответе, отражая любое происхождение, указанное в запросе в ответе. Это эффективно достигает ‘ * ‘ без его использования. Причина этого заключается в том, что он позволяет использовать несколько других функций CORS, включая возможность отправки AJAX XMLHttpRequest с атрибутом ‘withCredentials’, установленным в — это правда.

более гибкий подход заключается в использовании выражений Apache 2.4. Вы можете сопоставить Домены, пути и почти все другие переменные запроса. Хотя ответ есть * для всех, только запросчики, получающие этот ответ являются те, которые отвечают требованиям в любом случае.

Читать еще: Режимы создания таблиц в access

Что такое CORS

Многие из нас встречались с подобной ошибкой:

Access to XMLHttpRequest at ‘XXXX’ from origin ‘YYYY’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource..

Эта статья рассказывает что означает эта ошибка и как от нее избавиться.

Создадим тестовый сайт на Node.js с открытым API и запустим его по адресу http://127.0.0.1:3000.

Пусть там будет примерно такая функция получения GET запроса:

Пусть там будет простая функция входа в систему, где пользователи вводят общее секретное слово secret и им затем ему устанавливается cookie, идентифицируя их как аутентифицированных:

И пусть у нас будет некое приватное API для каких нибудь личных данных в /private, только для аутентифицированных пользователей.

Запрос нашего API через AJAX из других доменов

И допустим у нас есть какое-нибудь клиентское приложение работающее с нашим API. Но учтем что, наше API находится по адресу http://127.0.0.1:3000/public, а наш клиент размещен на http://127.0.0.1:8000, и на клиенте есть следующий код:

И это не будет работать!

Если мы посмотрим на вкладку network в консоле Хрома при обращение c http://127.0.0.1:8000 к http://127.0.0.1:3000 то там не будет ошибок:

Сам по себе запрос был успешным, но результат оказался не доступен. Описание причины можно найти в консоли JavaScript:

Ага! Нам не хватает заголовка Access-Control-Allow-Origin. Но зачем он нам и для чего он вообще нужен?

Same-Origin Policy

Причиной, по которой мы не получим ответ в JavaScript, является Same-Origin Policy. Эта ограничительная мера была придумана разработчиками браузеров что бы веб-сайт не мог получить ответ на сгенерированный AJAX запрос к другому веб-сайту находящемуся по другому адресу .

Например: если вы заходите на sample.org, вы бы не хотели, чтобы этот веб-сайт отправлял запрос к примеру на ваш банковский веб-сайт и получал баланс вашего счета и транзакции.

Same-Origin Policy предотвращает именно это.

«источник (origin)» в этом случае состоит из

протокол (например http )
хост (например example.com )
порт (например 8000 )

Так что http://sample.org и http://www.sample.org и http://sample.org:3000 – это три разных источника.

Пару слов о CSRF

Обратите внимание, что существует класс атак, называемый подделкой межсайтовых запросов (Cross Site Request Forgery – csrf ), от которых не защищает Same-Origin Policy.

При CSRF-атаке злоумышленник отправляет запрос сторонней странице в фоновом режиме, например, отправляя POST запрос на веб-сайт вашего банка. Если у вас в этот момент есть действительный сеанс с вашим банком, любой веб-сайт может сгенерировать запрос в фоновом режиме, который будет выполнен, если ваш банк не использует контрмеры против CSRF.

Так же обратите внимание, что, несмотря на то, что действует Same-Origin Policy, наш пример запроса с сайта secondparty.com на сайте 127.0.0.1:3000 будет успешно выполнен – мы просто не соможем получить доступ к результатам. Но для CSRF нам не нужен результат …

Например, API, которое позволяет отправлять электронные письма, выполняя POST запрос, отправит электронное письмо, если мы предоставим ему правильные данные. Злоумышленнику не нужно заботится о результате, его забота это отправляемое электронное письмо, которое он получит независимо от возможности видеть ответ от API.

Включение CORS для нашего публичного API

Допустим нам нужно разрешить работу JavaScript на сторонних сайтах (например, 127.0.0.1:8000) что бы получать доступ к нашим ответам API. Для этого нам нужно включить CORS в заголовок ответа от сервера. Это делается на стороне сервера:

Здесь мы устанавливаем заголовку Access-Control-Allow-Origin значение *, что означает: что любому хосту разрешен доступ к этому URL и ответу в браузере:

Непростые запросы и предварительные запросы (preflights)

Предыдущий пример был так называемым простым запросом. Простые запросы – это:

Запросы: GET,POST
Тип содержимого следующего:
- text/plain
- application/x-www-form-urlencoded
- multipart/form-data

Допустим теперь 127.0.0.1:8000 немного меняет реализацию, и теперь он обрабатывает запросы в формате JSON:

Но это снова все ломает!
На этот раз консоль показывает другую ошибку:

Любой заголовок, который не разрешен для простых запросов, требует предварительного запроса (preflight request).

Этот механизм позволяет веб-серверам решать, хотят ли они разрешить фактический запрос. Браузер устанавливает заголовки Access-Control-Request-Headers и Access-Control-Request-Method, чтобы сообщить серверу, какой запрос ожидать, и сервер должен ответить соответствующими заголовками.

Но наш сервер еще не отвечает с этими заголовками, поэтому нам нужно добавить их:

Теперь мы снова может получить доступ к ответу.

Credentials и CORS

Теперь давайте предположим, что нам нужно залогинится на 127.0.0.1:3000 что бы получить доступ к /private с конфиденциальной информацией.

При всех наших настройках CORS может ли другой сайт так же получить эту конфиденциальную информацию?

Мы пропустили код реализации входа в на сервер так как он не обязателен для объяснения материала.

Независимо от того, попытаемся ли мы залогинится на 127.0.0.1:3000 или нет, мы увидим «Please login first».

Причина в том, что cookie от 127.0.0.1:3000 не будут отправляться, когда запрос поступает из другого источника. Мы можем попросить браузер отправить файлы cookie клиенту, даже если запрос с других доменов:

Но опять это не будет работать в браузере. И это хорошая новость, на самом деле.

Итак, мы не хотим, чтобы злоумышленник имел доступ к приватным данным, но что, если мы хотим, чтобы 127.0.0.1:8000 имел доступ к /private?
В этом случае нам нужно установить для заголовка Access-Control-Allow-Credentials значение true:

Но это все равно пока еще не сработает. Это опасная практика – разрешать любые аутентифицированные запросы с других источников.

Браузер не позволит нам так легко совершить ошибку.

Если мы хотим разрешить 127.0.0.1:8000 доступ к /private, нам нужно указать точный источник в заголовке:

Теперь http://127.0.0.1:8000 также имеет доступ к приватным данным, в то время как запрос с любого другого сайта будет заблокирован.

Разрешить множественные источники (origin)

Теперь мы разрешили одному источнику делать запросы к другому источнику с данными аутентификации. Но что, если у нас есть несколько других источников?

В этом случае мы, вероятно, хотим использовать белый список:

Опять же: не отправляйте напрямую req.headers.origin в качестве разрешенного заголовка CORS. Это позволит любому веб-сайту получить доступ к приватным данным.
Из этого правила могут быть исключения, но, по крайней мере, дважды подумайте, прежде чем внедрять CORS с учетными данными без белого списка.

Заключение

В этой статье мы рассмотрели Same-Origin Policy и то, как мы можем использовать CORS, чтобы разрешать запросы между источниками, когда это необходимо.

Читать еще: Команды запросов в access

Это требует настройки на стороне сервера и на стороне клиента и в зависимости от запроса вызовет предварительный (preflight) запрос.

При работе с аутентифицированными запросами перекрестного происхождения следует проявлять дополнительную осторожность. Белый список может помочь разрешить нескольким источникам без риска утечки конфиденциальных данных (которые защищены аутентификацией).

Выводы

Браузер использует Same-origin policy, чтобы не обрабатывать AJAX ответы от веб-сайтов расположенных на адресах отличных от адреса с которого была загружена веб страница.
Same-origin policy не запрещает генерировать запросы к другим сайтам, но запрещает обрабатывать от них ответ.
CORS (Cross-Origin Resource Sharing) механизм, который использует дополнительные заголовки HTTP, чтобы дать браузерам указание предоставить веб-приложению, работающему в одном источнике, доступ к ответу на запрос к ресурсам из другого источника.
CORS вместе с credentials (с данными аутентификации) требует осторожности.
CORS это браузерная политика. Другие приложения не затрагиваются этим понятием.

XMLHttpRequest: кросс-доменные запросы

Материал на этой странице устарел, поэтому скрыт из оглавления сайта.

Более новая информация по этой теме находится на странице https://learn.javascript.ru/fetch-crossorigin.

Обычно запрос XMLHttpRequest может делать запрос только в рамках текущего сайта. При попытке использовать другой домен/порт/протокол – браузер выдаёт ошибку.

Существует современный стандарт XMLHttpRequest, он ещё в состоянии черновика, но предусматривает кросс-доменные запросы и многое другое.

Большинство возможностей этого стандарта уже поддерживаются всеми браузерами, но увы, не в IE9-.

Впрочем, частично кросс-доменные запросы поддерживаются, начиная с IE8, только вместо XMLHttpRequest нужно использовать объект XDomainRequest.

Кросс-доменные запросы

Разберём кросс-доменные запросы на примере кода:

Мы создаём XMLHttpRequest и проверяем, поддерживает ли он событие onload . Если нет, то это старый XMLHttpRequest , значит это IE8,9, и используем XDomainRequest .
Запрос на другой домен отсылается просто указанием соответствующего URL в open . Он обязательно должен быть асинхронным, в остальном – никаких особенностей.

Контроль безопасности

Кросс-доменные запросы проходят специальный контроль безопасности, цель которого – не дать злым хакерам™ завоевать интернет.

Серьёзно. Разработчики стандарта предусмотрели все заслоны, чтобы «злой хакер» не смог, воспользовавшись новым стандартом, сделать что-то принципиально отличное от того, что и так мог раньше и, таким образом, «сломать» какой-нибудь сервер, работающий по-старому стандарту и не ожидающий ничего принципиально нового.

Давайте, на минуточку, вообразим, что появился стандарт, который даёт, без ограничений, возможность делать любой странице HTTP-запросы куда угодно, какие угодно.

Как сможет этим воспользоваться злой хакер?

Он сделает свой сайт, например http://evilhacker.com и заманит туда посетителя (а может посетитель попадёт на «злонамеренную» страницу и по ошибке – не так важно).

Когда посетитель зайдёт на http://evilhacker.com , он автоматически запустит JS-скрипт на странице. Этот скрипт сделает HTTP-запрос на почтовый сервер, к примеру, http://gmail.com . А ведь обычно HTTP-запросы идут с куками посетителя и другими авторизующими заголовками.

Поэтому хакер сможет написать на http://evilhacker.com код, который, сделав GET-запрос на http://gmail.com , получит информацию из почтового ящика посетителя. Проанализирует её, сделает ещё пачку POST-запросов для отправки писем от имени посетителя. Затем настанет очередь онлайн-банка и так далее.

Спецификация CORS налагает специальные ограничения на запросы, которые призваны не допустить подобного апокалипсиса.

Запросы в ней делятся на два вида.

Простыми считаются запросы, если они удовлетворяют следующим двум условиям:

Простой метод: GET, POST или HEAD
Простые заголовки – только из списка:

Accept
Accept-Language
Content-Language
Content-Type со значением application/x-www-form-urlencoded , multipart/form-data или text/plain .

«Непростыми» считаются все остальные, например, запрос с методом PUT или с заголовком Authorization не подходит под ограничения выше.

Принципиальная разница между ними заключается в том, что «простой» запрос можно сформировать и отправить на сервер и без XMLHttpRequest, например при помощи HTML-формы.

То есть, злой хакер на странице http://evilhacker.com и до появления CORS мог отправить произвольный GET-запрос куда угодно. Например, если создать и добавить в документ элемент

Кросдоменные запросы на примере шрифтов и заголовок Access-Control-Allow-Origin

В файл .htaccess в каталоге, в котором находятся файлы шрифтов добавим следующие директивы (при отсутствии .htaccess его нужно создать):

Header set Access-Control-Allow-Origin «*»

При запросе файлов с расширением ttf, otf, eot или woff веб-сервер Apache (чаще всего используется он и передавать информацию путем указания директив .htaccess можно только ему) будет добавлять необходимый заголовок.

Header set Access-Control-Allow-Origin «*»

Заголовок предполагает, что шрифты может получать любой из сайтов в Интернете, можно ограничить доступ непосредственно указав имя ресурса. Несколько адресов при этом указать нельзя.

Access-Control-Allow-Origin: http://www.mysite.com
На стороне, на которой планируем использовать шрифты в файле CSS пропишем полные к ним пути

Это может выглядеть так:

@font-face <
font-family: ‘AudiNormal’;
src: url(‘http://www.mysite.com/css/fonts/League_Gothic.eot?’) format(‘eot’),
url(‘http://www.mysite.com/css/fonts/League_Gothic.woff’) format(‘woff’),
url(‘http://www.mysite.com/css/fonts/League_Gothic.ttf’) format(‘truetype’),
url(‘http://www.mysite.com/css/fonts/League_Gothic.svg’)

Или так (для каждого шрифта задаются определенные опции):

@font-face <
font-family: «AudiNormal»;
font-style: normal;
font-weight: normal;
src: url(‘http://www.mysite.com/style/auditype-normal.ttf’);
>
@font-face <
font-family: «AudiBold»;
font-style: normal;
font-weight: normal;
src: url(‘http://www.mysite.com/style/auditype-bold.ttf’);
>
@font-face <
font-family: «AudiExtNormal»;
font-style: normal;
font-weight: normal;
src: url(‘http://www.mysite.com/style/auditype-extendednormal.ttf’);
>
@font-face <
font-family: «AudiExtBold»;
font-style: normal;
font-weight: normal;
src: url(‘http://www.mysite.com/style/auditype-extendedbold.ttf’);
>

Схема с официального сайта Mozilla, объясняющая принципы работы CORS

Обширную информацию по теме можно найти на официальном сайте Mozilla и на сайтах других популярных браузеров.

Заголовок cors access control allow origin

CORS — Cross-Origin Resource Sharing

curl -I http://www.mysite.com/style/auditype-extendednormal.ttf

HTTP/1.1 200 OK
Server: nginx
Date: Thu, 27 Jul 2017 08:54:38 GMT
Content-Length: 326620
Connection: keep-alive
X-Accel-Version: 0.01
Last-Modified: Wed, 26 Jul 2017 12:46:15 GMT
ETag: «21c6399-4fbdc-55537d562407a»
Accept-Ranges: bytes
Access-Control-Allow-Origin: *

Заголовок, как видно, добавился, но используя curl -I запрос отправляется методом HEAD, чтобы же работали кросдоменные запросы тот же заголовок должен отдаваться в ответ на запрос методом GET

Обратимся к тому же шрифты используя curl, но отправим запрос в этот раз методом GET

curl -i -H «Accept: application/json» «Content-Type: application/json» -X GET http://mysite.com/style/auditype-extendednormal.ttf | head

Чтобы заголовок отдавался корректно необходимо чтобы был активирован mod_headers в Apache

Он активируется командой

После активации модуля веб-сервер необходимо перезагрузить

Access control allow origin может задаваться в конфигурации Apache, но обычно это делается через файл .htaccess способом приведенным в первой части данного материала