В Python я с большим успехом использовал библиотеку Flask-CORS . Это делает работу с CORS супер легкой и безболезненной. Я добавил код из документации библиотеки ниже.

Установка:

$ pip install -U flask-cors

Простой пример, который позволяет CORS для всех доменов на всех маршрутах:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/")
def helloWorld():
  return "Hello, cross-origin-world!"

Более подробные примеры см. в документации. Я использовал простой пример выше, чтобы обойти проблему CORS в ионном приложении, которое я создаю, чтобы получить доступ к отдельному серверу фляшек.

Для совместного использования поперечного сечения установите заголовок: 'Access-Control-Allow-Origin':'*';

Php: header('Access-Control-Allow-Origin':'*');

Узел: app.use('Access-Control-Allow-Origin':'*');

Это позволит делиться контента для разных доменов.

Используя React и Axios, присоедините прокси-ссылку к URL-адресу и добавьте заголовок, как показано ниже

https://cors-anywhere.herokuapp.com/ + Your API URL

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

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }

Всякий раз, когда я начинаю думать о CORS, моя интуиция о том, какой сайт содержит заголовки, неверна, как вы описали в своем вопросе. Для меня это помогает думать о цели одной и той же политики происхождения.

Цель той же политики происхождения - защитить вас от вредоносного JavaScript на сайте. Доступ к частной информации, которую вы решили поделиться только с siteB.com. Без такой же политики происхождения JavaScript, написанный авторами сайта site.com, может заставить ваш браузер делать запросы на siteB.com, используя ваши файлы cookie для проверки подлинности на сайте site.com. Таким образом, siteA.com может украсть секретную информацию, которую вы делитесь с сайтом site.com.

Иногда вам нужно работать с перекрестным доменом, в который входит CORS. CORS расслабляет ту же самую исходную политику для domainA. com, используя заголовок Access-Control-Allow-Origin, чтобы перечислить другие домены (domainB.com), которым доверено запускать JavaScript, который может взаимодействовать с domainA.com.

Чтобы понять, какой домен должен обслуживать заголовки CORS, рассмотрите это , Вы посещаете malicious.com, который содержит JavaScript, который пытается сделать запрос перекрестного домена на mybank.com. Это должно быть до mybank.com, а не malicious.com, чтобы решить, устанавливает ли он заголовки CORS, которые ослабляют одну и ту же политику происхождения, позволяя JavaScript от malicious.com взаимодействовать с ним. Если бы malicous.com мог устанавливать свои собственные заголовки CORS, позволяющие использовать свой собственный JavaScript-доступ к mybank.com, это полностью аннулирует ту же самую политику происхождения.

Я думаю, что причиной моей плохой интуиции является Точка зрения у меня при разработке сайта. Его мой сайт, со всем моим JavaScript, поэтому он не делает ничего злонамеренного, и мне следует определить, с какими другими сайтами может взаимодействовать JavaScript. Когда на самом деле я должен думать, какие другие сайты JavaScript пытаются взаимодействовать с моим сайтом, и должен ли я использовать CORS для их разрешения?

Я работаю с выражением 4 и узлом 7.4 и угловым, у меня была такая же проблема: помогите мне: a) сторона сервера: в файле app.js я даю заголовки всем ответам вроде:

app.use(function(req, res, next) {  
      res.header('Access-Control-Allow-Origin', req.headers.origin);
      res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
      next();
 });  

это должно быть до всех маршрутизаторов. Я видел много добавленных заголовков:

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

, но мне это не нужно, б) на стороне клиента: в send ajax вам нужно добавить: «withCredentials: true», например:

$http({
     method: 'POST',
     url: 'url, 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

удачи.

Если вы хотите просто протестировать кросс-доменное приложение, в котором браузер блокирует ваш запрос, вы можете просто открыть свой браузер в небезопасном режиме и протестировать приложение без изменения кода и не сделать ваш код небезопасным. Из MAC OS вы можете сделать это из терминальной линии:

open -a Google\ Chrome --args --disable-web-security --user-data-dir

Если вы используете PHP, попробуйте добавить следующий код в beaning файла php:

, если вы используете localhost, попробуйте следующее:

header("Access-Control-Allow-Origin: *");

if вы используете внешние домены, такие как сервер, попробуйте следующее:

header("Access-Control-Allow-Origin: http://www.website.com");

1. Клиент загружает javascript-код MyCode.js из http: // siteA - источник.

Код, который выполняет загрузку - ваш тег html-скрипта или xhr из javascript или что-то еще - откуда, скажем, http: // siteZ . И когда браузер запрашивает MyCode.js, он отправляет заголовок Origin: «Origin: http: // siteZ », потому что он может видеть, что вы запрашиваете siteA и siteZ! = SiteA , (Вы не можете остановить или вмешаться в это.)

2. Заголовок ответа MyCode.js содержит Access-Control-Allow-Origin: http: // siteB , который, как я думал, означал, что MyCode.js разрешено делать ссылки на перекрестные ссылки на сайт B.

no. Это означает, что для этого запроса разрешен только сайтB. Таким образом, ваш запрос для MyCode.js с сайтаZ получает вместо него ошибку, и браузер обычно ничего не дает. Но если вы вернете сервер A-C-A-O: siteZ, вы получите MyCode.js. Или, если он отправит «*», это сработает, что позволит каждому войти. Или если сервер всегда отправляет строку из заголовка Origin: ... ... ... для безопасности, если вы боитесь хакеров , ваш сервер должен разрешать только исходные данные в списке, которые разрешены для выполнения этих запросов.

Затем MyCode.js поступает из сайтаA. Когда он делает запросы на сайтB, все они перекрестно-происхождения, браузер отправляет Origin: siteA, а siteB должен принимать сайтA, распознавать его в кратком списке разрешенных пользователей и отправлять A-C-A-O: siteA. Только тогда браузер позволит вашему скрипту получить результат этих запросов.

Совместное использование запросов - CORS (запрос AJAX кросс-домена AKA) - проблема, с которой может столкнуться большинство веб-разработчиков, в соответствии с политикой Same-Origin-Policy, браузеры ограничивают клиентский JavaScript в изолированной программной среде безопасности, обычно JS не может напрямую взаимодействовать с удаленным сервером из другого домена. В прошлом разработчики создали много сложных способов для достижения запроса ресурсов между доменами, наиболее часто используемыми способами являются:

1. Использование Flash / Silverlight или серверной стороны в качестве «прокси» для связи с удаленным.
2. JSON с заполнением ( JSONP ).
3. Вставляет удаленный сервер в iframe и обменивается данными через фрагмент или window.name, см. здесь .

Эти сложные способы имеют более или менее некоторые проблемы, например, JSONP может привести к дыре в безопасности, если разработчики просто «оценят» его и # 3 выше, хотя он работает, оба домена должны строить строгий контракт между собой, он не гибкий и не элегантный IMHO:)

W3C внедрил совместное использование ресурсов Cross-Origin (CORS) в качестве стандартного решения для обеспечения безопасного, гибкого и рекомендуемого стандартного способа решения этой проблемы.

Механизм

С высокого уровня мы можем просто считать, что CORS - это контракт между клиентом AJAX-вызовом из домена A и страницей, размещенной в домене B, типичным запросом Cross-Origin / ответ будет:

Заголовки заголовков DomainA AJAX

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

Заголовки ответа домена B

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

Синие части, отмеченные выше, были фактами ядра, Заголовок запроса «Origin» указывает, откуда отправляется запрос на перекрестный запрос или запрос перед полетом », заголовок ответа« Access-Control-Allow-Origin »указывает, что эта страница позволяет удаленный запрос от DomainA (если значение * указывает, что удаленные запросы от любой домен).

Как я уже упоминал выше, W3 рекомендовал браузер для реализации «предпродажного запроса» перед отправкой HTTP-запроса на основе Cross-Origin, в двух словах это запрос HTTP OPTIONS:

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Если foo.aspx поддерживает HTTP-ключ OPTIONS, он может возвращать ответ, как показано ниже:

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

Только если ответ содержит «Access-Control-Allow-Origin», И его значение равно «*» или содержит домен, который отправил запрос CORS, выполнив этот запрос условия для условий запроса, передаст фактический запрос кросс-домена и кеширует результат в «Preflight-Result-Cache».

Я писал о CORS три года назад: HTTP-запрос AJAX Cross-Origin

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

Согласно этой статье Mozilla Developer Network,

Ресурс создает HTTP-запрос с кросс-началом, когда он запрашивает ресурс из другого домена или порта, чем тот, который обслуживает первый ресурс.

HTML-страница, поданная с http://domain-a.com, делает запрос <img> src для http://domain-b.com/image.jpg.

Политика одинакового происхождения

По соображениям безопасности браузеры ограничивают доступ к ресурсам, например, стилям CSS, изображениям и сценариям из отдельных доменов. сквозные HTTP-запросы, инициированные из сценариев. Например, XMLHttpRequest и Fetch следуют политике одного и того же происхождения. Таким образом, веб-приложение, использующее XMLHttpRequest или Fetch, могло только делать HTTP-запросы в своем собственном домене.

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

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

Механизм совместного использования ресурсов Cross-Origin (CORS) предоставляет средствам междоменного доступа к веб-серверам, которые обеспечивают безопасную передачу данных между доменами. Современные браузеры используют CORS в контейнере API - например, XMLHttpRequest или Fetch - для уменьшения рисков HTTP-запросов с кросс-началом.

Как работает CORS (заголовок Access-Control-Allow-Origin)

Wikipedia :

Стандарт CORS описывает новые заголовки HTTP, которые предоставляют браузеру и серверам возможность запрашивать удаленные URL-адреса только тогда, когда у них есть разрешение.

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

Пример

1. Браузер отправляет запрос OPTIONS с заголовком Origin HTTP. Значение этого заголовка - это домен, который обслуживал родительскую страницу. Когда страница из http://www.example.com пытается получить доступ к данным пользователя в service.example.com, следующий заголовок запроса будет отправлен на service.example.com: Происхождение: http://www.example.com
2. Сервер в service.example.com может ответить: заголовком Access-Control-Allow-Origin (ACAO) в своем ответе, указывающим, какие исходные сайты разрешены. Например: Access-Control-Allow-Origin: http://www.example.com Страница с ошибкой, если сервер не разрешает перекрестный запрос заголовка заголовка Access-Control-Allow-Origin (ACAO) с подстановочным знаком, который разрешает все домены: Access-Control-Allow-Origin: *