Совместное использование ресурсов между источниками (CORS)

На самом деле все.

В частности, эта статья предназначена для веб-администраторов , разработчики серверов и разработчики интерфейсов . Современные браузеры обрабатывают клиентскую часть обмена данными между источниками, включая заголовки и применение политик. Но стандарт CORS означает, что серверы должны обрабатывать новые заголовки запросов и ответов. Еще одна статья для разработчиков серверов, обсуждающая совместное использование между источниками с точки зрения сервера (с фрагментами кода PHP), — дополнительная литература.

Этот стандарт совместного использования между источниками может разрешать 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 .

Например предположим, что веб-контент в 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  

В отличие от» простых запросов «(обсужденных выше) для «предварительно настроенных» запросов браузер сначала отправляет 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 , и поскольку задан настраиваемый заголовок, этот запрос выполняется заранее.

Давайте посмотрим на полный обмен между клиентом и сервером. Первый обмен — это предварительный запрос/ответ :

  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 требовал такого поведения, но впоследствии был изменен, чтобы он больше не требовался. Однако не все браузеры реализовали это изменение и поэтому по-прежнему демонстрируют поведение, которое требовалось изначально.

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

• Измените поведение на стороне сервера, чтобы избежать предварительной проверки и/или избежать перенаправления.
• Измените запрос таким образом что это простой запрос, который не вызывает предполетной проверки.

Если это невозможно, то другой способ:

1. Сделайте простой запрос (используя Response.url для Fetch API или XMLHttpRequest. responseURL ), чтобы определить, по какому URL-адресу окажется реальный предварительно обработанный запрос.
2. Сделайте другой запрос («настоящий» запрос), используя URL-адрес, полученный из Response .url или XMLHttpRequest.responseURL на первом шаге.

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

Наиболее интересная возможность, предоставляемая обоими 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-ответов, которые серверы отправляют обратно для запросов управления доступом, как определено в спецификации совместного использования ресурсов между источниками. В предыдущем разделе дается обзор их в действии..

Возвращаемый ресурс может иметь один 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 позволяет серверу заносить в белый список заголовки, которые 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:  

Параметр delta-seconds указывает количество секунд, в течение которых результаты могут быть кэшированы.

Заголовок Access-Control-Allow-Credentials Указывает, может ли быть предоставлен ответ на запрос, если флаг credentials имеет значение true. При использовании как части ответа на предварительный запрос это указывает, может ли фактический запрос быть выполнен с использованием учетных данных. Обратите внимание, что простые запросы GET не проходят предварительную проверку, поэтому, если запрос сделан для ресурса с учетными данными, если этот заголовок не возвращается с ресурсом, ответ игнорируется браузером, а не возвращается в веб-контент.

 Access-Control-Allow-Credentials: true 

Запросы с учетными данными обсуждаются выше.

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

 Access-Control-Allow-Methods:  [, ] * 

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

Заголовок Access-Control-Allow-Headers используется в ответ на предпечатный запрос, чтобы указать, какие HTTP-заголовки могут использоваться при выполнении фактического запроса. Этот заголовок является ответом на стороне сервера на заголовок браузера Access-Control-Request-Headers .

 Access-Control-Allow-Headers:   [,  ]*

В этом разделе перечислены заголовки, которые клиенты могут использовать при отправке HTTP-запросы для использования функции совместного использования между источниками. Обратите внимание, что эти заголовки устанавливаются для вас при обращении к серверам. Разработчикам, использующим возможность межсайтового XMLHttpRequest , не нужно программно устанавливать какие-либо заголовки запроса на совместное использование между источниками.

Заголовок Origin указывает источник запроса межсайтового доступа или запроса предварительной проверки.

 Origin:  

Источник — это URI, указывающий сервер, с которого инициирован запрос. Он не включает никакой информации о пути, а только имя сервера.

Обратите внимание, что в любом запросе управления доступом заголовок Origin всегда отправлено.

Access-Control-Request -Method используется при выдаче предпечатного запроса, чтобы дать серверу знать, какой HTTP-метод будет использоваться при фактическом запросе.

 Access-Control-Request-Method:  

Примеры этого использования можно найти выше.

Заголовок Access-Control-Request-Headers используется при выдаче предварительного запроса, чтобы сообщить серверу, какие заголовки HTTP будут использоваться при выполнении фактического запроса (например, с setRequestHeader () ). На этот заголовок на стороне браузера будет отвечать дополнительный заголовок на стороне сервера Access-Control-Allow-Headers .

 Access-Control-Request-Headers:  [, ] * 

Примеры этого использования можно найти выше.

Таблица совместимости на этой странице создана на основе структурированных данных. Если вы хотите внести свой вклад в данные, посетите 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 настроена неправильно, консоль браузера отобразит ошибку, например «Запрос на другой источник заблокирован: та же политика источника запрещает чтение удаленного ресурса в $ somesite» , что указывает на то, что запрос был заблокирован из-за нарушения правил безопасности CORS. Однако это не обязательно может быть ошибкой настройки. Возможно, запрос на самом деле намеренно запрещен веб-приложением пользователя и удаленной внешней службой. Однако, если конечная точка должна быть доступна, для успешного выполнения потребуется некоторая отладка.

Чтобы понять основная проблема с конфигурацией CORS, вам нужно выяснить, какой запрос неисправен и почему. Эти шаги могут помочь вам в этом:

1. Перейдите на соответствующий веб-сайт или веб-приложение и откройте Инструменты разработчика..
2. Теперь попробуйте воспроизвести неудачную транзакцию и проверьте консоль, если вы видите сообщение об ошибке нарушения CORS. Вероятно, это будет выглядеть так:

Текст сообщения об ошибке будет примерно таким:

 Запрос на кросс-источник заблокирован: та же политика происхождения запрещает чтение удаленного ресурса по адресу  https://some  -url-здесь .  ( Причина: дополнительная информация здесь ). 

Консоль 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