0 Вопрос: fetch выдаёт мне ошибку CORS при запросе GET [дубликат]

вопрос создан в Thu, May 2, 2019 12:00 AM

ТЛ, др; О той же политике происхождения

У меня есть процесс Grunt, который запускает экземпляр сервера express.js. Это работало абсолютно нормально до тех пор, пока не началось обслуживание пустой страницы со следующим появлением в журнале ошибок в консоли разработчика в Chrome (последняя версия):

  

XMLHttpRequest не может загрузить https://www.example.com/       Заголовок «Access-Control-Allow-Origin» отсутствует в запрошенном       ресурс. Исходный код http: //localhost: 4300 поэтому запрещен.

Что мешает мне получить доступ к странице?

    
72
  1. Я работаю над сайтом, и пять минут назад все было в порядке.
    2016-02-22 12: 25: 00Z
  2. выдает заголовки CORS? возможно, если вы поделитесь кодом, его будет легче увидеть
    2016-02-22 12: 25: 56Z
  3. Правдоподобно. В какой отдел мне следует обратиться, чтобы узнать? Я просто делаю вещи с backbone.marionette в основном ...
    2016-02-22 12: 26: 52Z
  4. You should have enough with what I provided you - да ... это проблема CORS
    2016-02-22 12: 30: 41Z
  5. Да. Я полагаю, что организации отделов не всегда одинаковы, так что, возможно, это туманный вопрос, но я хотел бы узнать немного о бэкенде /маршрутизации /sys-admin в моей компании, и это было хорошим поводом для ознакомления. Я тоже, если в будущем возникнут проблемы, я могу помочь.
    2016-02-22 12: 32: 28Z
6 ответов                              6                         

О той же политике происхождения

Это Политика одинакового происхождения . Это функция безопасности, реализованная в браузерах.

Ваш конкретный случай показывает, как он реализован для XMLHttpRequest (и вы получите идентичные результаты, если будете использовать выборку), но он также применим к другим вещам (например, к изображениям, загруженным в <canvas>, или документам, загруженным в <iframe>), только с немного другими реализациями.

(Как ни странно, это также относится к CSS-шрифтам, но это потому, что найденные производители настаивали на DRM, а не на проблемах безопасности, которые обычно покрывает та же политика происхождения).

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

  • Алиса - это человек с веб-браузером
  • Боб управляет веб-сайтом (в вашем примере https://www.[website].com/)
  • Мэллори управляет веб-сайтом (в вашем примере http://localhost:4300)

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

Алиса посещает веб-сайт Мэллори, на котором есть некоторый JavaScript, который заставляет браузер Алисы отправлять HTTP-запрос на веб-сайт Боба (с ее IP-адреса с помощью файлов cookie и т. д.). Это может быть так же просто, как использовать XMLHttpRequest и прочитать responseText.

Политика одинакового происхождения браузера запрещает JavaScript читать данные, возвращаемые веб-сайтом Боба (к которым Боб и Алиса не хотят, чтобы Мэллори получала доступ). (Обратите внимание, что вы можете, например, отображать изображение с использованием элемента <img> в разных источниках, поскольку содержимое изображения не подвергается JavaScript (или Мэллори)… если вы не добавите холст в смесь, в этом случае вы будете генерировать ошибку нарушения того же происхождения).

Почему применяется та же политика происхождения, если вы не думаете, что она должна

Для любого заданного URL этоВозможно, что СОП не нужен. Вот несколько распространенных сценариев, в которых это происходит:

  • Алиса, Боб и Мэллори - это одно и то же лицо.
  • Боб предоставляет полностью открытую информацию

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

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

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

Нет третьей стороны (Мэллори), которая считается рискованной.

Почему вы можете отображать данные на странице, не читая их с помощью JS

Существует ряд обстоятельств, когда сайт Мэллори может заставить браузер получать данные от третьей стороны и отображать их (например, добавив элемент <img> для отображения изображения). JavaScript Мэллори не может прочитать данные на этом ресурсе, хотя это может сделать только браузер Алисы и сервер Боба, поэтому он по-прежнему безопасен.

CORS

Заголовок Access-Control-Allow-Origin, указанный в сообщении об ошибке, является частью CORS стандарт, который позволяет Бобу явно предоставлять разрешение сайту Мэллори на доступ к данным через браузер Алисы.

Базовая реализация будет просто включать:

Access-Control-Allow-Origin: *

… разрешить любому веб-сайту читать данные.

Access-Control-Allow-Origin: http://example.com/

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

Особенности того, как вы устанавливаете этот заголовок ответа, зависят от HTTP-сервера Боба и /или языка программирования на стороне сервера. Существует набор руководств для различных распространенных конфигураций , которые могут помочь.

 Модель применения правил CORS

Примечание: некоторые запросы являются сложными и отправляют предварительный просмотр ОПЦИИ запрашивают, что сервер должен будет ответить до того, как браузер отправит запрос GET /POST /PUT /независимо от того, что JS хочет сделать. Реализации CORS, которые только добавляют Access-Control-Allow-Origin к определенным URL-адресам, часто с этим сталкиваются.

Очевидно, что предоставление разрешения через CORS - это то, что Боб сделал бы только в том случае, если либо:

  • Данные не были частными или
  • Мэллори доверяли

Если вы также являетесь Бобом в этом сценарии, то особенности того, как вы добавляете заголовки разрешений CORS, будут зависеть от некоторой комбинации вашего выбора программного обеспечения сервера HTTP и того, какой язык вы используете для программирования на стороне сервера (если есть). р>

Мэллори не может добавить этот заголовок, потому что она должна получить разрешение с сайта Боба, и было бы глупо (вплоть до того, чтобы сделать SOP бесполезным), чтобы она могла дать себе разрешение ,

Сообщения об ошибках, в которых упоминается «Ответ на предпечатную проверку»

Некоторые запросы из разных источников предварительно подсвечены .

Это происходит, когда (грубо говоря) вы пытаетесь сделать перекрестный запрос, который:

  • Включает учетные данные, такие как файлы cookie
  • Не удалось сгенерировать с помощью обычной формы HTML (например, с пользовательскими заголовками или типом содержимого, который нельзя использовать в enctype формы).

Обратите внимание, что «пользовательские заголовки» включают Access-Control-Allow-Origin и другие заголовки ответа CORS. Они не относятся к запросу, не делают ничего полезного (в чем смысл системы разрешений, где вы можете предоставить себе разрешение?) И должны появляться только в ответе.

В этих случаях остальная часть этого ответа по-прежнему применяется , но вам также необходимо убедиться, что сервер может прослушивать запрос предварительной проверки (это будет OPTIONS (а не GET, POST или что-то еще) вы пытались отправить) и ответили на него с правильным заголовком Access-Control-Allow-Origin, а также с Access-Control-Allow-Methods и Access-Control-Allow-Headers, чтобы разрешить использовать ваши конкретные методы HTTP или заголовки.

Альтернативы CORS

JSONP

Боб мог также предоставить данные, используя взлом, например, JSONP , как люди пересекали Происхождение Ajax до появления CORS.

Он работает, представляя данные в форме программы JavaScript, которая внедряет данные на страницу Мэллори.

Требуется, чтобы Мэллори доверял Бобу, чтобы он не предоставлял вредоносный код.

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

Поскольку JSONP работает путем добавления элемента <script> для загрузки данных в форме программы JavaScript, которая вызывает функцию, уже находящуюся на странице, попытка использовать технику JSONP для URL-адреса, который возвращает JSON, завершится неудачно - обычно с помощью CORB ошибка - потому что JSON не является JavaScript.

Переместите два ресурса в один источник

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

Прокси-сервер

Мэллори могла использовать серверный код для извлечения данных (которые она затем могла бы передавать со своего сервера в браузер Алисы через HTTP, как обычно).

Это будет либо:

  • добавить заголовки CORS
  • преобразовать ответ в JSONP
  • существуют в том же источнике, что и документ HTML

Этот серверный код может быть размещен третьей стороной (например, YQL).

Бобу не нужно было давать никаких разрешений для этого.

Это было бы хорошо, так как это только между Мэллори и Бобом. Боб не может думать, что Мэллори - Алиса, и предоставлять Мэллори данные, которые должны храниться в секрете между Алисой и Бобом.

Следовательно, Мэллори может использовать эту технику только для чтения общедоступных данных.

Написание чего-то другого, кроме веб-приложения

Как отмечалось в разделе «Почему одна и та же политика происхождения применяется только к JavaScript на веб-странице», вы можете избежать SOP, не записывая JavaScript на веб-странице.

Это не значит, что вы не можете продолжать использовать JavaScript и HTML, но вы можете распространять их, используя другой механизм, например Node-WebKit или PhoneGap.

Расширения браузера

Расширение браузера может вставлять заголовки CORS в ответ до применения той же политики происхождения.

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

Они также, как правило, работают только с простыми запросами (сбой при обработке запросов предварительных опций).

Наличие надлежащей среды разработки с локальным сервером разработки обычно лучший подход.

Другие угрозы безопасности

Обратите внимание, что SOP /CORS не смягчают XSS , CSRF или SQL Injection атак, которые должны быть обработаны независимо.

Резюме

  • В вашем клиентском коде вы ничего не можете сделать, чтобы обеспечить CORS-доступ к кому-то другому серверу.
  • Если вы управляете сервером, запрос делается: Добавьте к нему разрешения CORS.
  • Если вы дружите с человеком, который его контролирует: попросите его добавить к нему разрешения CORS.
  • Если это общедоступная служба: прочтите документацию по API, чтобы узнать, что они говорят о доступе к ней с помощью клиентского JavaScript. Они могут попросить вас использовать определенные URL-адреса или использовать JSONP (или они могут вообще не поддерживать его).
  • Если ничего из вышеперечисленного не применимо: попросите браузер вместо этого поговорить с вашим сервером, а затем попросите сервер получить данные с другого сервера и передать их. (Существуют также сторонние размещенные службы, которые прикрепляют заголовки CORS к общедоступным ресурсам, которые вы можете использовать).
115
2019-02-01 11: 26: 32Z
  1. Если я запускаю локальную локальную сеть веб-сервер и пытаюсь выполнить загрузку AJAX с IP /URL, это будет работать? Я еще не пробовал это. так как мой веб-сервер, получающий данные JSON, будет MCU
    2016-12-23 05: 09: 49Z
  2. @ Ciastopiekarz - применяются обычные правила одного и того же источника /разные источники происхождения. Применяются нормальные правила сетевой маршрутизации.
    2016-12-23 12: 25: 58Z
  3. Самый полный ответ, который я когда-либо читал, а не просто ссылка о cors ..
    2017-04-22 18: 12: 08Z
  4. @ Квентин - Вау! +1! Так что я должен понять, что если Алиса использует расширение CORS, сервер считает, что ее http-вызовы не из javascript, а из расширения браузера, и обрабатывает его как обычный запрос того же источника?
    2017-05-11 11: 51: 38Z
  5. @ snippetkid - Нет. В обычном случае сервер будет отправлять заголовки CORS при любом ответе, и не имеет значения, откуда поступил запрос. Браузер отвечает за разрешение или запрет доступа к данным JS на основе заголовков CORS в ответе. (Ситуация на сервере становится немного сложнее, когда речь идет о предварительных запросах)
    2017-05-11 11: 54: 04Z

Целевой сервер должен разрешить перекрестный запрос. Чтобы разрешить его через экспресс, просто обработайте запрос параметров http:

app.options('/url...', function(req, res, next){
   res.header('Access-Control-Allow-Origin', "*");
   res.header('Access-Control-Allow-Methods', 'POST');
   res.header("Access-Control-Allow-Headers", "accept, content-type");
   res.header("Access-Control-Max-Age", "1728000");
   return res.sendStatus(200);
});
    
3
2016-09-09 10: 45: 32Z

Это происходит из-за ошибки CORS. CORS расшифровывается как Cross Source Resource Sharing. Проще говоря, эта ошибка возникает, когда мы пытаемся получить доступ к домену /ресурсу из другого домена.

Подробнее об этом читайте здесь: Ошибка CORS с jquery

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

Как получить крестик почтовый запрос совместного использования ресурсов (CORS)

Эти ссылки могут помочь

    
2
2017-05-23 12: 18: 02Z

Поскольку это не упоминается в принятом ответе.

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

Вы можете использовать простые запросы .
Для выполнения «простых запросов» запрос должен соответствовать нескольким условиям. Например. только разрешающий метод POST, GET и HEAD, а также разрешающий только некоторые заданные заголовки (вы можете найти все условия здесь ).

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

    
2
2018-12-18 08: 03: 31Z

Эта проблема CORS не получила дальнейшего развития (по другим причинам).

У меня эта проблема в настоящее время по другой причине. Мой интерфейс также возвращает ошибку заголовка «Access-Control-Allow-Origin».

Просто я указал неправильный URL, поэтому этот заголовок не был отражен должным образом (в котором я предположил, что он это сделал). localhost (передний конец) - > вызовите незащищенный http (должен быть https), убедитесь, что конечная точка API от внешнего интерфейса указывает на правильный протокол.

    
- 1
2018-12-17 06: 40: 45Z

Вы должны включить CORS, чтобы он заработал.

    
- 4
2017-04-17 11: 13: 49Z
источник размещен Вот