Вышеупомянутое - это типичный способ современной архитектуры веб-приложений.
Бэкэнд (api.example.com) запускается на совершенно другом компьютере, и его API доступен для доступа с любого типа интерфейса. У нас был наш интерфейс React (app.example.com), среда разработки которого построена с использованием webpack. Вызовы api выполняются с использованием axios.

Из-за этой архитектуры нам приходится делать запросы CORS к нашему собственному бэкэнду. Совместное использование ресурсов между разными источниками (CORS) - это механизм, который позволяет запрашивать ресурсы с ограниченным доступом на веб-странице из другого домена за пределами домена, из которого был обслужен первый ресурс. В Mozilla Developer Network есть отличный документ, который я рекомендую читателям.

CORS применяется во всех современных браузерах. Наши запросы останавливаются браузером, поскольку они считают, что наш сайт (app.example.com) пытается отправить запрос в отдельный источник (api.example.com), то есть на наш сервер.

Проблема # 1

Браузер отправляет предварительные вызовы OPTIONS перед любыми запросами GET / POST, если они не классифицируются как простые запросы.

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

Решение # 1

Если вы хотите отправлять Authorization заголовки, лучше настроить ваш сервер так, чтобы это позволяло. Настройте свой сервер так, чтобы он отвечал на OPTIONS запрос по этому URL-адресу заголовком Access-Control-Allow-Headers: Authorization.

Проблема # 2

Ответ на предпечатный запрос не проходит проверку контроля доступа: на запрошенном ресурсе отсутствует заголовок «Access-Control-Allow-Origin». Следовательно, к источнику http: // localhost: 3000 доступ запрещен. Ответ имел код состояния HTTP 401.

Решение # 2

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

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

Решение # 3

Установите этот Chrome-плагин, который отключает проверку безопасности CORS хромами.



vitvad / Access-Control-Allow-Origin
Access-Control-Allow-Origin - расширение Chrome… github.com



Это решило проблему №2, но проблема №1 не была решена. Также нецелесообразно полностью отключать CORS, поскольку это приводит к неправильной работе некоторых сайтов. Кроме того, плагин не обновлялся с 2015 года, и в нем была ошибка, которая не позволяла PATCH запросов. Таким образом, нам пришлось пропустить этот плагин

Решение # 4

Наконец, мы перенаправили запросы с вашего сервера приложений (того, который обслуживает ваше созданное приложение и ресурсы), который пересылает их на бэкэнд. А поскольку переадресация вызовов осуществляется с сервера на сервер, а не от браузера к серверу, мы успешно избегаем ВСЕХ предполетных запросов CORS!

Шаги по перенаправлению вызовов на серверную часть через сервер приложений:

Просто добавьте поле proxy в свой package.json, например:

"proxy": "api.exampple.com",

Таким образом, вызов, который ранее был api.example.com/posts/post_id, станет app.example.com/api/posts/post_id, который затем будет перенаправлен на в любом случае внутренний маршрут.

Также убедитесь, что вы используете axios, чтобы закомментировать свой baseURL

//axios.defaults.baseURL = ’api.example.com’

Имейте в виду, что proxy действует только в процессе разработки (с npm start), и вы должны убедиться, что URL-адреса указывают на то, что нужно в рабочей среде.

Параметр proxy поддерживает соединения HTTP, HTTPS и WebSocket.
Если параметр proxy недостаточно гибок для вас, можно также:

И все! Наслаждайтесь избеганием этих неприятных вызовов OPTIONS, используя указанную выше опцию :)