Совместное использование ресурсов между источниками (CORS) — это механизм на основе HTTP-заголовка, который позволяет серверу указывать любые другие источники (домен, схема или порт), отличные от его собственного, из которого браузер должен разрешать загрузку ресурсов. CORS также полагается на механизм, с помощью которого браузеры отправляют «предварительный» запрос на сервер, на котором размещен ресурс из разных источников, чтобы проверить, разрешит ли сервер фактический запрос. В этой предварительной проверке браузер отправляет заголовки, которые указывают метод HTTP и заголовки, которые будут использоваться в фактическом запросе.
Пример запроса между источниками: интерфейсный код JavaScript, обслуживаемый из https://domain-a.com
использует XMLHttpRequest
для выполнения запроса для https://domain-b.com/data .json
.
По соображениям безопасности браузеры ограничивают HTTP-запросы между источниками, инициируемые из скриптов. Например, XMLHttpRequest
и Fetch API придерживаются одной политики происхождения. Это означает, что веб-приложение, использующее эти API, может запрашивать ресурсы только из того же источника, из которого было загружено приложение, если только ответ из другого источника не содержит правильные заголовки CORS.
Механизм CORS поддерживает безопасные запросы из разных источников и передачу данных между браузерами и серверами. Современные браузеры используют CORS в таких API-интерфейсах, как XMLHttpRequest
или Fetch, чтобы снизить риски HTTP-запросов из разных источников.
- Кому следует прочитать эту статью?
- Какие запросы используют CORS?
- Обзор функций
- Примеры сценариев управления доступом
- Простые запросы
- Предварительно проверенные запросы
- Предварительно настроенные запросы и перенаправления
- Запросы с учетными данными
- Запросы с учетными данными и подстановочные знаки
- Заголовки HTTP-ответов
- Access-Control-Allow-Origin
- Access-Control-Expose-Headers
- Access-Control -Max-Age
- Access-Control-Allow-Credentials
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Заголовки HTTP-запроса
- Origin
- Access-Control-Request-Method
- Access-Control-Request-Headers
- Технические характеристики
- Совместимость с браузером
- Примечания по совместимости
- Ошибки CORS
- Выявление проблемы
- Сообщения об ошибках CORS
Кому следует прочитать эту статью?
На самом деле все.
В частности, эта статья предназначена для веб-администраторов , разработчики серверов и разработчики интерфейсов . Современные браузеры обрабатывают клиентскую часть обмена данными между источниками, включая заголовки и применение политик. Но стандарт CORS означает, что серверы должны обрабатывать новые заголовки запросов и ответов. Еще одна статья для разработчиков серверов, обсуждающая совместное использование между источниками с точки зрения сервера (с фрагментами кода PHP), — дополнительная литература.
Какие запросы используют CORS?
Этот стандарт совместного использования между источниками может разрешать HTTP-запросы между сайтами для:
- Вызовов
XMLHttpRequest
или Fetch API, как описано выше. - Веб-шрифты (для междоменного использования шрифтов в
@ font-face
в CSS), чтобы серверы могли развертывать шрифты TrueType, которые могут быть загружены и использованы только между сайтами, которым это разрешено. - Текстуры WebGL.
- Изображения/видеокадры, нарисованные на холсте с использованием
drawImage ()
. - CSS-фигуры из изображений.
Эта статья представляет собой общее обсуждение ресурса Cross-Origin. Совместное использование и включает обсуждение необходимых заголовков HTTP.
Обзор функций
Стандарт совместного использования ресурсов между источниками работает путем добавления новых заголовков HTTP, которые позволяют серверам описывать разрешенные источники чтобы прочитать эту информацию из веб-браузера. Кроме того, для методов HTTP-запроса, которые могут вызывать побочные эффекты для данных сервера (в частности, HTTP-методы, отличные от GET
или POST
с определенными типами MIME) , спецификация требует, чтобы браузеры выполняли предварительную проверку запроса, запрашивая поддерживаемые методы с сервера с помощью метода запроса HTTP OPTIONS
, а затем, после «утверждения» сервером, отправляли фактический запрос. Серверы также могут информировать клиентов о том, следует ли отправлять с запросами «учетные данные» (такие как файлы cookie и HTTP-аутентификация).
Ошибки CORS приводят к ошибкам, но по соображениям безопасности подробности об ошибке недоступны для JavaScript . Код знает, что произошла ошибка. Единственный способ определить, что именно пошло не так, — это посмотреть подробную информацию в консоли браузера.
В последующих разделах обсуждаются сценарии, а также приводится разбивка используемых заголовков HTTP.
Примеры сценариев управления доступом
Мы представляем три сценария, демонстрирующих, как работает совместное использование ресурсов между источниками. Во всех этих примерах используется XMLHttpRequest
, который может выполнять межсайтовые запросы в любом поддерживающем браузере.
Обсуждение совместного использования ресурсов между источниками с точки зрения сервера (включая Фрагменты кода PHP) можно найти в статье Управление доступом на стороне сервера (CORS).
Простые запросы
Некоторые запросы не запускайте предварительную проверку CORS. В этой статье они называются «простыми запросами» , хотя в спецификации Fetch (которая определяет CORS) этот термин не используется. «Простой запрос» — это запрос, который удовлетворяет всем следующим условиям :
- Один из разрешенных методов:
-
ПОЛУЧИТЬ
HEAD
-
POST
-
- Помимо заголовков, автоматически устанавливаемых пользовательским агентом (например,
Connection
,User- Agent
или другие заголовки, определенные в спецификации Fetch как «запрещенное имя заголовка»), единственные заголовки, которые разрешено устанавливать вручную, — это те, которые спецификация Fetch определяет как «заголовок запроса в безопасном списке CORS. ”, А именно:Accept
Accept-Language
Content-Language
-
Content-Type
(но обратите внимание на дополнительные требования ниже)
- Единственные допустимые значения для заголовка
Content-Type
:-
application /x-www-form-urlencoded
-
multipart/form-data code >
text/plain
-
- Никаких прослушивателей событий не зарегистрировано ни на каком
XMLHttpRequest. загрузить
объект, используемый в запросе; доступ к ним осуществляется с помощью свойстваXMLHttpRequest.upload
. - В запросе не используется объект
ReadableStream
.
Примечание. WebKit Nightly и Safari Technology Предварительный просмотр накладывает дополнительные ограничения на значения, разрешенные в заголовках Accept
, Accept-Language
и Content-Language
. Если какой-либо из этих заголовков имеет «нестандартные» значения, WebKit/Safari не считает запрос «простым запросом». Какие значения WebKit/Safari считают «нестандартными», не задокументировано, за исключением следующих ошибок WebKit:
- Требовать предварительной проверки для нестандартных заголовков запросов из безопасного списка CORS Accept, Accept-Language и Content-Language
- Разрешить запятые в заголовках запросов Accept, Accept-Language и Content-Language для простых CORS
- Переключиться на модель черного списка для ограниченных заголовков Accept в простых запросах CORS
Никакие другие браузеры не реализуют эти дополнительные ограничения, потому что они не являются частью спецификации.
Например предположим, что веб-контент в https://foo.example
хочет вызвать контент в домене https://bar.other
. Код такого рода может использоваться в JavaScript, развернутом в foo.example
:
const xhr = new XMLHttpRequest (); const url = ' https://bar.other/resources/public-data/'; xhr.open (' GET ', url); xhr.onreadystatechange = someHandler; xhr.send ();
Это выполняет простой обмен между клиентом и сервером, используя заголовки CORS для обработки привилегий:
Давайте посмотрим, что браузер отправит на сервер в этом случае, и посмотрим, как сервер отреагирует:
GET/ ресурсы/public-data/HTTP/1.1 Хост: bar.other Агент-пользователя: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv: 71.0) Gecko/20100101 Firefox/71.0 Принять: text/html, application/xhtml + xml , application/xml; q = 0.9, */*; q = 0.8Accept-Language: en-us, en; q = 0.5 Accept-Encoding: gzip, deflateConnection: keep-aliveOrigin: https://foo.example
Примечательный заголовок запроса — Origin
, что показывает, что вызов происходит из https://foo.example
.
HTTP/1. 1 200 OK Дата: Пн, 1 декабря 2008 г. 00:23:53 GMTServer: Apache/2 Access-Control-Allow-Origin: * Keep-Alive: timeout = 2, max = 100Connection: Keep -AliveTransfer-Encoding: chunkedContent-Type: application/xml [… XML-данные…]
В ответ сервер отправляет обратно Access-Control-Allow-Origin
заголовок с Access-Control-Allow-Origin: *
, что означает, что к ресурсу может получить доступ любой источник.
Access-Control-Allow-Origin: *
Этот шаблон Origin
и Access -Control-Allow-Origin
— это простейшее использование протокола управления доступом. Если владельцы ресурса в https://bar.other
хотели ограничить доступ к ресурсу только для запросов из https:// foo.example
(т.е. ни один домен, кроме https://foo.example
не может получить доступ к ресурсу в межсайтовой манере) они отправят:
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Origin
вместо указания « *
«подстановочный знак. Предварительно проверенные запросы
В отличие от» простых запросов «(обсужденных выше) для «предварительно настроенных» запросов браузер сначала отправляет HTTP-запрос с использованием метода OPTIONS
к ресурсу в другом источнике, чтобы определить, безопасен ли фактический запрос для отправки. Межсайтовые запросы предварительно обрабатываются таким образом, поскольку они могут иметь последствия для пользовательских данных.
Ниже приводится пример запроса, который будет предварительно обработан:
const xhr = new XMLHttpRequest (); xhr.open ('POST', 'https://bar.other/resources/post-here/'); xhr.setRequestHeader ('X-PINGOTHER', 'pingpong' ); xhr.setRequestHeader ('Content-Type', 'application/xml'); xhr.onreadystatechange = handler; xhr.send (' Arun ');
В приведенном выше примере создается тело XML для отправки с запросом POST
. Также установлен нестандартный заголовок запроса HTTP X-PINGOTHER
. Такие заголовки не являются частью HTTP/1.1, но обычно полезны для веб-приложений. Поскольку в запросе используется Content-Type
из application/xml
, и поскольку задан настраиваемый заголовок, этот запрос выполняется заранее.
Примечание : как как описано ниже, фактический запрос POST
не включает заголовки Access-Control-Request- *
; они нужны только для запроса OPTIONS
.
Давайте посмотрим на полный обмен между клиентом и сервером. Первый обмен — это предварительный запрос/ответ :
OPTIONS/doc HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv: 71.0) Gecko/20100101 Firefox/71.0 Принимать: text/html, application/xhtml + xml, application/xml; q = 0.9, */*; q = 0.8 Accept-Language: en-us, en; q = 0.5 Accept-Encoding: gzip, deflateConnection: keep-aliveOrigin: http://foo.exampleAccess-Control-Request-Method: POSTAccess-Control-Request-Headers: X-PINGOTHER, Content-TypeHTTP /1.1 204 Нет содержимого Дата: понедельник, 1 декабря 2008 г. 01:15:39 GMTServer: Apache/2Access-Control-Allow-Origin: https://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control- Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400 Варианты: Accept-Encoding, OriginKeep-Alive: timeout = 2, max = 100Connection: Keep-Alive
Строки 1–10 выше представляют запрос предварительной проверки с помощью метода OPTIONS
. Браузер определяет, что ему необходимо отправить это, на основе параметров запроса, которые использовались в приведенном выше фрагменте кода JavaScript, чтобы сервер мог ответить, приемлемо ли отправить запрос с фактическими параметрами запроса. OPTIONS — это метод HTTP/1.1, который используется для определения дополнительной информации с серверов и является безопасным методом, то есть его нельзя использовать для изменения ресурса. Обратите внимание, что вместе с запросом OPTIONS отправляются два других заголовка запроса (строки 9 и 10 соответственно):
Access-Control-Request-Method: POSTAccess-Control-Request-Headers: X-PINGOTHER , Content-Type
Заголовок Access-Control-Request-Method
уведомляет сервер как часть предварительного запроса о том, что при отправке фактического запроса он быть отправлено с помощью метода запроса POST
. Заголовок Access-Control-Request-Headers
уведомляет сервер о том, что при отправке фактического запроса он будет отправлен с X-PINGOTHER
и Content-Type
настраиваемые заголовки. Теперь у сервера есть возможность определить, желает ли он принять запрос в этих обстоятельствах.
Строки 13–22 выше представляют собой ответ, который сервер отправляет обратно, что указывает на то, что метод запроса ( POST
) и заголовки запроса ( X-PINGOTHER
) приемлемы. В частности, давайте посмотрим на строки 16-19:
Access-Control-Allow-Origin: http://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control- Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400
Сервер отвечает Access-Control-Allow-Origin: http://foo .example
, ограничивая доступ только запрашивающим исходным доменом. Он также отвечает Access-Control-Allow-Methods
, в котором говорится, что POST
и GET
являются жизнеспособными методами для запроса рассматриваемый ресурс (этот заголовок аналогичен заголовку ответа Allow
, но используется строго в контексте управления доступом).
Сервер также отправляет Access-Control-Allow-Headers
со значением « X-PINGOTHER, Content-Type
«, подтверждая, что это разрешенные заголовки для использования с фактическим запросом. Как и Access-Control-Allow-Methods
, Access-Control-Allow-Headers
представляет собой список допустимых заголовков, разделенных запятыми.
Наконец, Access-Control-Max-Age
дает значение в секундах, в течение которого можно кэшировать ответ на предварительный запрос без отправки другого предварительного запроса. В этом случае 86400 секунд — это 24 часа. Обратите внимание, что у каждого браузера есть максимальное внутреннее значение, которое имеет приоритет, когда Access-Control-Max-Age
больше.
После завершения запроса предварительной проверки отправляется реальный запрос:
POST/doc HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv: 71.0) Gecko /20100101 Firefox/71.0Accept: text/html, application/xhtml + xml, application/xml; q = 0.9, */*; q = 0.8 Accept-Language: en-us, en; q = 0.5 Accept-Encoding: gzip , deflateConnection: keep-aliveX-PINGOTHER: pingpongContent-Type: text/xml; charset = UTF-8Referer: https://foo.example/examples/preflightInvocation.htmlContent-Length: 55Origin: https://foo.examplePragma: no-cacheCache-Control: no-cache Arun HTTP/1.1 200 OK Дата: понедельник, 1 декабря 2008 г. 01:15:40 GMTServer: Apache/2Access-Control-Allow-Origin: https://foo.exampleVary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 235Keep-Alive: timeout = 2, max = 99Connection: Keep-AliveContent-Type: text/plain [Некоторая полезная нагрузка XML]
Предварительно настроенные запросы и перенаправления
В настоящее время не все браузеры поддерживают следующие перенаправления после предварительного запроса. Если перенаправление происходит после предварительного запроса, некоторые браузеры в настоящее время будут сообщать об ошибке, например следующее.
Запрос был перенаправлен на https://example.com/ foo ‘, который запрещен для запросов с перекрестным источником, требующих предварительной проверки
Запрос требует предварительной проверки, которая запрещена для выполнения перенаправления с перекрестным источником
Первоначально протокол CORS требовал такого поведения, но впоследствии был изменен, чтобы он больше не требовался. Однако не все браузеры реализовали это изменение и поэтому по-прежнему демонстрируют поведение, которое требовалось изначально.
Пока браузеры не догонят спецификацию, вы можете обойти это ограничение, выполнив одно или оба из следующих вариантов:
- Измените поведение на стороне сервера, чтобы избежать предварительной проверки и/или избежать перенаправления.
- Измените запрос таким образом что это простой запрос, который не вызывает предполетной проверки.
Если это невозможно, то другой способ:
- Сделайте простой запрос (используя
Response.url
для Fetch API илиXMLHttpRequest. responseURL
), чтобы определить, по какому URL-адресу окажется реальный предварительно обработанный запрос. - Сделайте другой запрос («настоящий» запрос), используя URL-адрес, полученный из
Response .url
илиXMLHttpRequest.responseURL
на первом шаге.
Однако, если запрос является тем, который запускает предполетную проверку из-за наличие заголовка Authorization
в запросе, вы не сможете обойти ограничение, используя описанные выше действия. И вы вообще не сможете обойти это, если у вас нет контроля над сервером, на который делается запрос.
Запросы с учетными данными
Примечание . При отправке учетных запросов в другой домен по-прежнему будут применяться политики сторонних файлов cookie. Политика всегда применяется независимо от любой настройки на сервере и клиенте, как описано в этой главе.
Наиболее интересная возможность, предоставляемая обоими XMLHttpRequest
или Fetch и CORS — это возможность делать «учетные» запросы, которые знают о файлах cookie HTTP и информации аутентификации HTTP. По умолчанию при межсайтовых вызовах XMLHttpRequest
или Fetch браузеры не отправляют учетные данные. При вызове объекта XMLHttpRequest
или конструктора Request
необходимо установить специальный флаг.
В этом примере , содержимое, изначально загруженное из http://foo.example
, выполняет простой запрос GET к ресурсу на http://bar.other
, который устанавливает файлы cookie. Контент в foo.example может содержать такой JavaScript:
const invocation = new XMLHttpRequest (); const url = 'http://bar.other/resources/credentialed-content /'; функция callOtherDomain () {если (вызов) {invocation.open (' GET ', url, true); invocation.withCredentials = true; invocation.onreadystatechange = обработчик; invocation.send (); }}
Строка 7 показывает флаг для XMLHttpRequest
, который должен быть установлен для вызова с помощью файлов cookie, а именно withCredentials
логическое значение. По умолчанию вызов осуществляется без файлов cookie. Поскольку это простой запрос GET
, он не выполняется заранее, но браузер отклоняет любой ответ, не имеющий Access- Control-Allow-Credentials
: true
и not делают ответ доступным для вызывающего веб-содержимого.
Вот пример обмена между клиентом и сервером:
GET/resources/credentialed-content/HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv: 71.0) Gecko/20100101 Firefox/71.0Accept: text /html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us, en; q = 0. 5 Accept-Encoding: gzip, deflateConnection: keep-aliveReferer: http://foo.example/examples/credential.htmlOrigin: http://foo.exampleCookie: pageAccess = 2HTTP/1.1 200 OK Дата: понедельник, 1 декабря 2008 г., 01:34 : 52 GMTServer: Apache/2Access-Control-Allow-Origin: https://foo.exampleAccess-Control-Allow-Credentials: trueCache-Control: no-cachePragma: no-cacheSet-Cookie: pageAccess = 3; expires = среда, 31 декабря 2008 г. 01:34:53 GMTVary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 106Keep-Alive: timeout = 2, max = 100Connection: Keep-AliveContent-Type: text/plain [ text/plain payload]
Хотя строка 10 содержит cookie, предназначенный для содержимого на http://bar.other
, если bar.other не ответил с помощью Access-Control-Allow-Credentials
: true
(строка 17), ответ будет проигнорирован и не станет доступным для веб-содержимого.
Запросы с учетными данными и подстановочные знаки
При ответе на запрос с учетными данными сервер должен указать источник в значении Access-Control-Allow-Origin
вместо указания подстановочного знака « *
».
Поскольку заголовки запроса в приведенном выше Например, включая заголовок Cookie
, запрос завершится ошибкой, если значение заголовка Access-Control-Allow-Origin
будет «*». Но это не сработает: поскольку значение заголовка Access-Control-Allow-Origin
— « http://foo.example
» (фактическое origin), а не подстановочный знак « *
», содержимое с учетными данными возвращается вызывающему веб-содержимому.
Обратите внимание, что параметр Set Заголовок ответа -Cookie
в приведенном выше примере также устанавливает дополнительный файл cookie. В случае сбоя возникает исключение — в зависимости от используемого API.
Обратите внимание, что файлы cookie, установленные в ответах CORS, регулируются обычными политиками сторонних файлов cookie. В приведенном выше примере страница загружается из foo.example
, но файл cookie в строке 20 отправляется bar.other
и поэтому не будет сохраняется, если пользователь настроил свой браузер так, чтобы отклонять все сторонние файлы cookie.
Cookie в запросе (строка 10) также может быть подавлен в обычных политиках сторонних файлов cookie. Таким образом, принудительная политика файлов cookie может аннулировать возможность, описанную в этой главе, эффективно препятствуя тому, чтобы вы вообще делали запросы с учетными данными.
Будет применяться политика файлов cookie вокруг атрибута SameSite.
Заголовки HTTP-ответов
В этом разделе перечислены заголовки HTTP-ответов, которые серверы отправляют обратно для запросов управления доступом, как определено в спецификации совместного использования ресурсов между источниками. В предыдущем разделе дается обзор их в действии..
Access-Control-Allow-Origin
Возвращаемый ресурс может иметь один Access-Control-Allow -Origin
со следующим синтаксисом:
Access-Control-Allow-Origin: | *
Access-Control-Allow-Origin
указывает либо одно происхождение, которое сообщает браузерам разрешить этому источнику доступ к ресурсу; или иначе — для запросов без учетных данных — подстановочный знак « *
«, чтобы указать браузерам разрешить любому источнику доступ к ресурсу.
Например, чтобы разрешить коду из источника https://mozilla.org
получить доступ к ресурсу, вы можете указать:
Access-Control- Allow-Origin: https://mozilla.orgVary: Origin
Если сервер указывает одно происхождение (которое может динамически меняться в зависимости от запрашивающего источника как часть белого списка), а не « *
«, тогда сервер также должен включить Origin
в заголовок ответа Vary
, чтобы указать клиентам, что ответы сервера будут отличаться в зависимости от значения заголовка запроса Origin
.
Access-Control-Expose-Headers
Заголовок Access-Control-Expose-Headers
позволяет серверу заносить в белый список заголовки, которые Javascript (например, getResponseHeader ()
) в браузерах разрешено согласно ess.
Access-Control-Expose-Headers: [, ] *
Например, следующее:
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
… позволит X- Заголовки My-Custom-Header
и X-Another-Custom-Header
для отображения в браузере.
Access-Control -Max-Age
Заголовок Access-Control-Max-Age
указывает, как долго результаты предварительного запроса могут быть кэшированы. Пример запроса предварительной проверки см. В примерах выше.
Access-Control-Max-Age:
Параметр delta-seconds
указывает количество секунд, в течение которых результаты могут быть кэшированы.
Access-Control-Allow-Credentials
Заголовок Access-Control-Allow-Credentials
Указывает, может ли быть предоставлен ответ на запрос, если флаг credentials
имеет значение true. При использовании как части ответа на предварительный запрос это указывает, может ли фактический запрос быть выполнен с использованием учетных данных. Обратите внимание, что простые запросы GET
не проходят предварительную проверку, поэтому, если запрос сделан для ресурса с учетными данными, если этот заголовок не возвращается с ресурсом, ответ игнорируется браузером, а не возвращается в веб-контент.
Access-Control-Allow-Credentials: true
Запросы с учетными данными обсуждаются выше.
Access-Control-Allow-Methods
Access-Control-Allow-Methods
заголовок определяет метод или методы, разрешенные при доступе к ресурсу. Это используется в ответ на предполетный запрос. Условия, при которых выполняется предварительная проверка запроса, обсуждались выше.
Access-Control-Allow-Methods: [, ] *
Пример запроса предполетной проверки приведен выше, включая пример отправки этого заголовка в браузер.
Access-Control-Allow-Headers
Заголовок Access-Control-Allow-Headers
используется в ответ на предпечатный запрос, чтобы указать, какие HTTP-заголовки могут использоваться при выполнении фактического запроса. Этот заголовок является ответом на стороне сервера на заголовок браузера Access-Control-Request-Headers
.
Access-Control-Allow-Headers: [, ]*
Заголовки HTTP-запроса
В этом разделе перечислены заголовки, которые клиенты могут использовать при отправке HTTP-запросы для использования функции совместного использования между источниками. Обратите внимание, что эти заголовки устанавливаются для вас при обращении к серверам. Разработчикам, использующим возможность межсайтового XMLHttpRequest
, не нужно программно устанавливать какие-либо заголовки запроса на совместное использование между источниками.
Origin
Заголовок Origin
указывает источник запроса межсайтового доступа или запроса предварительной проверки.
Origin:
Источник — это URI, указывающий сервер, с которого инициирован запрос. Он не включает никакой информации о пути, а только имя сервера.
origin
может быть null
или URI. Обратите внимание, что в любом запросе управления доступом заголовок Origin
всегда отправлено.
Access-Control-Request-Method
Access-Control-Request -Method
используется при выдаче предпечатного запроса, чтобы дать серверу знать, какой HTTP-метод будет использоваться при фактическом запросе.
Access-Control-Request-Method:
Примеры этого использования можно найти выше.
Access-Control-Request-Headers
Заголовок Access-Control-Request-Headers
используется при выдаче предварительного запроса, чтобы сообщить серверу, какие заголовки HTTP будут использоваться при выполнении фактического запроса (например, с setRequestHeader ()
). На этот заголовок на стороне браузера будет отвечать дополнительный заголовок на стороне сервера Access-Control-Allow-Headers
.
Access-Control-Request-Headers: [, ] *
Примеры этого использования можно найти выше.
Технические характеристики
Технические характеристики | Статус | Комментарий |
---|---|---|
Fetch Определение «CORS» в эта спецификация. |
Уровень жизни | Новое определение; заменяет спецификацию W3C CORS. |
Совместимость с браузером
Таблицы BCD загружаются только в браузере
Таблица совместимости на этой странице создана на основе структурированных данных. Если вы хотите внести свой вклад в данные, посетите https://github.com/mdn/browser-compat-data и отправьте нам запрос на перенос.
Примечания по совместимости
Internet Explorer 8 и 9 раскрывают CORS через XDomainRequest
, но полностью реализован в IE 10
- Ошибки CORS
- Включить CORS: I хочу добавить поддержку CORS на свой сервер
XMLHttpRequest
- Fetch API
- Будет ли это CORS ? — интерактивное объяснение и генератор CORS.
- Использование CORS со всеми (современными) браузерами
- Как запустить браузер Chrome без CORS
- Stack Ответ переполнения с информацией «как сделать» для решения типичных проблем:
- Как избежать предварительной проверки CORS
- Как использовать прокси CORS для обхода «Нет заголовка Access-Control-Allow-Origin»
- Как исправить «Заголовок Access-Control-Allow-Origin не должен быть подстановочным знаком»
Ошибки CORS
Совместное использование ресурсов между источниками (CORS) — это стандарт, который позволяет серверу ослабить политику одного источника. Это используется, чтобы явно разрешить одни запросы из разных источников и отклонить другие. Например, если сайт предлагает встраиваемую услугу, может потребоваться ослабить определенные ограничения. Настроить такую конфигурацию CORS не обязательно просто и могут возникнуть некоторые проблемы. На этих страницах мы рассмотрим некоторые распространенные сообщения об ошибках CORS и способы их устранения.
Если конфигурация CORS настроена неправильно, консоль браузера отобразит ошибку, например «Запрос на другой источник заблокирован: та же политика источника запрещает чтение удаленного ресурса в $ somesite»
, что указывает на то, что запрос был заблокирован из-за нарушения правил безопасности CORS. Однако это не обязательно может быть ошибкой настройки. Возможно, запрос на самом деле намеренно запрещен веб-приложением пользователя и удаленной внешней службой. Однако, если конечная точка должна быть доступна, для успешного выполнения потребуется некоторая отладка.
Выявление проблемы
Чтобы понять основная проблема с конфигурацией CORS, вам нужно выяснить, какой запрос неисправен и почему. Эти шаги могут помочь вам в этом:
- Перейдите на соответствующий веб-сайт или веб-приложение и откройте Инструменты разработчика..
- Теперь попробуйте воспроизвести неудачную транзакцию и проверьте консоль, если вы видите сообщение об ошибке нарушения CORS. Вероятно, это будет выглядеть так:
Текст сообщения об ошибке будет примерно таким:
Запрос на кросс-источник заблокирован: та же политика происхождения запрещает чтение удаленного ресурса по адресу https://some -url-здесь . ( Причина: дополнительная информация здесь ).
Примечание. По соображениям безопасности, подробности о том, что пошло неправильно с запросом CORS недоступны для кода JavaScript . Код знает, что произошла ошибка. Единственный способ определить, что именно пошло не так, — это посмотреть подробную информацию в консоли браузера.
Сообщения об ошибках CORS
Консоль Firefox отображает сообщения в своей консоли, когда запросы не выполняются из-за CORS. Часть текста ошибки — это сообщение «причина», которое дает дополнительное понимание того, что пошло не так. Сообщения о причинах перечислены ниже; щелкните сообщение, чтобы открыть статью, в которой более подробно объясняется ошибка и предлагаются возможные решения.
- Причина: CORS отключен
- Причина: запрос CORS выполнен не удалось
- Причина: нельзя добавить заголовок CORS ‘Origin’
- Причина: внешнее перенаправление запроса CORS не разрешено
- Причина: CORS запрос не http
- Причина: отсутствует заголовок CORS ‘Access-Control-Allow-Origin’
- Причина: заголовок CORS ‘Access-Control-Allow-Origin’ не соответствует ‘xyz’
- Причина: учетные данные не поддерживаются, если заголовок CORS ‘Access-Control-Allow-Origin’ равен ‘*’
- Причина: не удалось найти метод в заголовке CORS ‘Access-Control-Allow-Methods’
- Причина: ожидалось ‘true’ в заголовке CORS ‘Access-Control-Allow-Credentials’
- Причина : Канал предварительной проверки CORS не прошел.
- Причина: недопустимый токен ‘xyz’ в заголовке CORS ‘Access-Control-Allow-Methods’
- Причина: недопустимый токен ‘xyz ‘в заголовке CORS’ Access-Control-Allow-Header s ‘
- Причина: отсутствует токен’ xyz ‘в заголовке CORS’ Access-Control-Allow-Headers ‘из канала предварительной проверки CORS.
- Причина: несколько заголовков CORS’ Доступ -Control-Allow-Origin ‘не допускается
- Глоссарий: CORS
- Введение в CORS
- Настройки CORS на стороне сервера
- Изображение с включенным CORS
- Атрибуты настроек CORS
- https://www.test-cors.org — страница для тестирования запросов CORS