Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Access control allow

fastcodenote

Страницы

вторник, 11 февраля 2014 г.

CORS. Как посылать запросы GET, POST, DELETE etc.

В наши дни не знать что такое CORS (wiki), сродни прогулки тёмной ночью по последнему этажу, недостроенной высотки где-нибудь за городом, в неблагополучном районе. Т.е. смертеподнобно, а особенно если вы фронт-енд разработчик.

Более подробно вы можете ознакомиться перейдя по ссылкам в конце текста, я же скажу вкратце, CORS это набор HTTP заголовков, которые позволяют объяснить браузеру и серверу, что они хоть и из разных доменов, но одной крови работать могут вместе. Т.е. кросс-доменные зпросы поддерживаються. Кто не знает, то запрос из браузера посредством старого, доброго JavaSctipt недавно, так на чистоту, без костылей сделать было невозможно. Ура, эти мрачные времена канули в лету. Пришёл на момощь CORS.

Речь пойдет именно о процессе использования и базовой настройки заголовков сервера, и отсыла запросов клиента с использованием jQuery.

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

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers

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

Access-Control-Allow-Origin — (обязательный) собственно список разделенный пробелами допустимых доменнов (источников), которые будут ломиться делать запросы к нам на сервер. Из особенностей: регистрозависим, поддерживает маски, например, http://api.superservice.com/, http://*.superservice.com/ или, как вы могли догадаться просто «звездочка» *. Этот заголовок будет сравниваться с заголовком Origin клиентского запроса.
Access-Control-Allow-Method — (обязательный) это список доступных HTTP методов, разделенных запятыми. Особое внимание стоит уделить тому, что «звездочка» аля * работать не будет!
Access-Control-Allow-Headers — (обязательный вместе с Access-Control-Request-Headers) список через запятую заголовков разрешенных в запросе.

Пример настройки для Apache:

Давайте разберемся, что тут происходит? А происходит следующее, запросы будут обработанны с любого источника, если они будут одного из перечисленных в Header always set Access-Control-Allow-Methods типов, так же будут подерживаться заголовки X-Requested-With и content-type

Тот же пример для PHP

Теперь, предположим, что сервис у нас крутится по адресу http://api.superservice.com/ , а GET запрос нам надо сделать со странички http://pure.client.net/. Это не сложно сделать, к примеру с jQuery:

Думаю самое время упомянуть о неприятном моменте с AngularJs если вам понадобиться сделать кросс-доменый запрос с помощью $http или $resource, то надо будет удалить один заголовок, делается это так:

Такое поведение странно, для меня, по крайней мере, несмотря на то что заголовок X-Requested-With вы укажите Access-Control-Allow-Headers не исключены проблемы с запросами. Ходят слухи что это бага AngularJs, кому интересно, если найдете что, отпишитесь в коментах.

Переходим к интересным запросам типа POST/PUT/DELETE, всех их объединяет то что они пытаются что-то изменить на сервере. Но как сделать такой запрос кросс-доменным? Сначала надо получить список заголовков типа Access-Control-*, делается это предварительным OPTIONS запросом. Который может вернуть тот же набор Access-Control-*, что и обычный метод GET.

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

Этот предварительный запрос (prefligth-запрос), делается автоматически jQuery или тем же Angular, по-тому же URL что и ваш основной запрос POST/PUT/DELETE поэтому будте внимательны если вы не сделаете правильной обработку запросов типа OPTIONS то и запрос POST/PUT/DELETE у вас сделать не получиться, из-за политики безопасности, который следуют браузеры.

Пример запроса POST с использованием jQuery.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать еще:  База данных access охранная служба

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

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

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

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

  1. Простой метод: GET, POST или HEAD
  2. Простые заголовки – только из списка:
  • 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-запрос куда угодно. Например, если создать и добавить в документ элемент

Комментарии

  • Если вам кажется, что в статье что-то не так — вместо комментария напишите на GitHub.
  • Для одной строки кода используйте тег , для нескольких строк кода — тег

, если больше 10 строк — ссылку на песочницу (plnkr, JSBin, codepen…)

  • Если что-то непонятно в статье — пишите, что именно и с какого места.
  • Как работает заголовок Access-Control-Allow-Origin?

    видимо, я совершенно неправильно понял его слова. Я подумал о чем-то подобном:—1—>

    1. клиент загружает код javascript MyCode.js от http://siteA —источник.
    2. заголовок ответа MyCode.Яш содержит Access-Control-Allow-Origin: http://siteB, что, как я думал, означало этот Микод.js было разрешено делать перекрестные ссылки на сайт B.
    3. клиент запускает некоторые функции Mycode в.js, которые в свою очередь делают запросы http://siteB, что должно быть хорошо, несмотря на запросы перекрестного происхождения.

    одно точно — я все еще не понимаю, как я должен использовать этот заголовок.

    У меня есть полный контроль сайт A и сайт B. Как включить код javascript, загруженный с сайта A, для доступа к ресурсам на сайте B с помощью этого заголовка?

    Я не хочу использовать JSONP.

    11 ответов

    когда сайт A пытается получить контент с сайта B, сайт B может отправить Access-Control-Allow-Origin заголовок ответа, чтобы сообщить браузеру, что содержимое этой страницы доступна в определенное происхождение. (An происхождения это домен, плюс схема и номер порта.) По умолчанию страницы сайта B имеют значение недоступно для любого другого источника; через Access-Control-Allow-Origin заголовок открывает дверь для доступа cross-origin специфическим запрашивая происхождением.

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

    современные браузеры не будут блокировать междоменные запросы напрямую. Если сайт A запрашивает страницу с сайта B, браузер фактически получит запрошенную страницу на сетевом уровне и проверьте, разрешен ли сайт списка заголовков ответов A как разрешенный домен отправителя. Если сайт B не указал, что сайту A разрешен доступ к этой странице, браузер запустит XMLHttpRequest ‘ s error event и запретить данные ответа на запрос кода JavaScript.

    не простые запросы

    что происходит на сетевом уровне может быть немного сложнее, чем описано выше. Если запрос «не простой» запрос, браузер сначала отправляет запрос параметров» preflight » без данных, чтобы убедитесь, что сервер примет запрос. Запрос не является простым, когда либо (или оба):

    • использование HTTP-глагола, отличного от GET или POST (например, PUT, DELETE)
    • используя не простой заголовков запроса; только простые запросы заголовки:
      • Accept
      • Accept-Language
      • Content-Language
      • Content-Type (это просто, только когда его значение application/x-www-form-urlencoded , multipart/form-data , или text/plain )

    если сервер отвечает на параметры preflight с соответствующими заголовками ответов ( Access-Control-Allow-Headers для не простых заголовков, Access-Control-Allow-Methods для не-простых глаголов), которые соответствуют не-простому глаголу и / или не-простым заголовкам, затем браузер отправляет фактический запрос.

    предположим, что сайт A хочет отправить запрос PUT для /somePage С не-простой Content-Type стоимостью application/json , браузер сначала отправит предполетный запрос:

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

    при отправке фактического запроса (после завершения предполетной подготовки) поведение идентично тому, как обрабатывается простой запрос. Другими словами, не простой запрос, префлайт которого успешен, обрабатывается так же, как простой запрос (т. е. сервер все равно должен отправить Access-Control-Allow-Origin снова для фактического ответа).

    браузеры отправляют фактический запрос:

    и сервер отправляет обратно Access-Control-Allow-Origin так же, как и для простого запроса:

    посмотреть понимание XMLHttpRequest над CORS для получения дополнительной информации о не простых запросах.

    Совместное Использование Запросов Cross-Origin — CORS (A. K. A. Междоменный запрос AJAX)-это проблема, с которой может столкнуться большинство веб-разработчиков, в соответствии с политикой того же происхождения, браузеры ограничивают клиентский JavaScript в песочнице безопасности, обычно JS не может напрямую связываться с удаленным сервером из другого домена. В прошлом разработчики создали много сложных способов достижения междоменного запроса ресурсов, чаще всего используя следующие способы:

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

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

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

    Читать еще:  Тип данных счетчик в access

    Механизм

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

    запрос AJAX DomainA заголовки

    заголовки ответов DomainB

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

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

    если Foo.aspx поддерживает параметры http-глагола, он может возвращать ответ, как показано ниже:

    только если ответ содержит «Access-Control-Allow-Origin» и его значение » * » или содержит домен, который отправил запрос CORS, удовлетворяя этому условию mandtory браузер будет отправьте фактический Междоменный запрос и кэшируйте результат в «Предварительный Результат-Кэш«.

    Я написал в блоге о CORS три года назад:AJAX перекрестный HTTP-запрос

    Что такое 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 Forgerycsrf ), от которых не защищает 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».

    Читать еще:  Тип функции pointer to c

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

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

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

    Выводы

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

    Настройка CORS в Nginx

    CORS (cross-origin resource sharing) — совместное использование ресурсов между разными источниками . Это спецификация, которая обеспечивает действительно открытый доступ между доменами. Если вы размещаете общедоступный контент, рассмотрите возможность использования CORS, чтобы открыть его для универсального доступа из JavaScript в браузерах.

    До недавнего времени основным способом преодоления ограничений, наложенных в same-origin-policy относительно XSS запросов, было использование JSONP . Сам JSONP имеет неустранимое ограничение — позволяет только получение данных GET методом , то есть отправка данных через POST метод остается недоступной.

    Почему CORS важен?

    За последние годы JavaScript и веб-программирование активно развиваются, но same-origin политику никто не отменял. Это препятствует тому, чтобы JavaScript делал запросы между разными доменами, что породило различные хаки для выполнения междоменных запросов.

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

    Правило ограничения домена (Same Origin Policy, Принцип одинакового источника) — это важная концепция безопасности для некоторых языков программирования на стороне клиента, таких как JavaScript. Политика разрешает сценариям, находящимся на страницах одного сайта, доступ к методам и свойствам друг друга без ограничений, но предотвращает доступ к большинству методов и свойств для страниц на разных сайтах. Одинаковые источники — это источники, у которых совпадают три признака: домен, порт и протокол.

    Концепция правила ограничения домена появилась во времена Netscape Navigator 2.0. Скрытые производные оригинальной разработки используются во всех современных браузерах, а также в плагинах, таких как Adobe Flash либо для механизмов отличных от DOM манипуляций, таких как XMLHttpRequest.

    Как это работает?

    ля инициации Cross-origin запроса браузер клиента добавляет в HTTP запрос Origin (домен сайта, с которого происходит запрос). Например страница http://www.a.com/page.html пытается получить данные со страницы http://www.b.com/cors.txt. В случае если браузер клиента поддерживает технологию CORS, запрос будет выглядеть так:

    Если сервер www.b.com хочет разрешить получение данных с www.a.com то в ответе сервера будет присутствовать строчка:

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

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

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

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

    Пример конфигурации CORS для web-сервера Nginx

    Читайте также

    Nginx — легковесный, по сравнению с Apache, HTTP, обратный прокси сервер написанный Igor Sysoe. Официальную документацию к Nginx вы найдете здесь.…

    Как регламентировать перекуры в течение рабочего дня? Можно ли разрешать опаздывать к началу рабочего дня? Можно ли чатится во время…

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

    Ссылка на основную публикацию
    Adblock
    detector