Понимание CORS

CORS или Cross Origin Resource Sharing - это механизм http, позволяющий пользователю получить доступ к ресурсам, расположенным в домене, отличном от того, в котором находится сайт, с помощью некоторых дополнительных заголовков. Так, например, предположим, что ваше приложение, расположенное на https://test1.domain.com, должно выполнить REST-вызов API, расположенного на https://test2.domain.com/some/awesome/endpoint.

Теперь по умолчанию браузер не разрешает такой запрос. Это сделано из соображений безопасности http. Это означает, что браузер не разрешит запросу, сделанному из сценария на веб-странице, получить доступ к любым HTTP-ресурсам, расположенным в домене, отличном от того, с которого изначально был загружен сайт. Например, как XMLHttpRequest, так и Fetch API придерживаются политики одного и того же происхождения. Вот где на помощь приходит CORS. CORS облегчает такое поведение, сначала проверяя test2.domain.com с помощью некоторых специальных заголовков.

Заголовки

Заголовки, относящиеся к CORS:

Заголовки запросов

  • Источник
  • Доступ-Контроль-Запрос-Метод
  • Заголовки запроса-контроля доступа

Заголовки ответов

  • Доступ-Контроль-Разрешить-Происхождение
  • Доступ-Контроль-Разрешить-Учетные данные
  • Access-Control-Expose-Заголовки
  • Доступ-Контроль-Макс-Возраст
  • Доступ-Контроль-Разрешить-Методы
  • Доступ-Контроль-Разрешить-Заголовки

Функциональный обзор

Принцип работы CORS:

  1. Браузер обнаруживает повторный запрос к test2.domain.com.
  2. Он проверяет, является ли запрос GET или HEAD. Если это так, он ищет любые настраиваемые заголовки HTTP. Если он их обнаруживает, он переходит к шагу 3, в противном случае он переходит к фактическому запросу, то есть к шагу 7.
  3. Затем браузер выполняет запрос OPTIONS test2.domain.com, используя следующие заголовки: Origin, Access-Control-Request-Method и Access-Control-Request.
  4. test2.domain.com теперь должен отвечать соответствующими заголовками Access-Control.
  5. Если соответствующие заголовки Access-Control- не найдены в ответе на запрос OPTIONS, поток завершается с ошибкой.
  6. Если в ответе на запрос OPTIONS обнаружены соответствующие заголовки Access-Control- *, переходите к шагу 7.
  7. Сделайте актуальный запрос.

Реализация

Теперь iftest2.domain.com, - это шлюз api, мы можем сделать его CORS-совместимым, просто включив параметры CORS в настройках шлюза. Однако, если вы окажетесь в ситуации, когда домен или даже шлюз не поддерживает эту функцию из коробки, не волнуйтесь, выход все же есть.

Вы можете настроить iRule в F5, чтобы вставить эти пользовательские заголовки, чтобы сделать test2.domain.com, CORS-совместимым

Вот и все.

Особый случай

Во время работы с CORS я обнаружил действительно интересный случай, о котором, думаю, стоит упомянуть здесь. Настройка была примерно такой: у меня был сайт на domain_a. Ему нужен был ресурс, размещенный в domain_b. Теперь, domain_b, будучи шлюзом API, я включил на шлюзе стандартные функции CORS и подумал, что это все. Я обнаружил, что все вызовы, поступающие на шлюз, проходили, за исключением одного конкретного вызова, который был ресурсом в приложении, размещенном на сервере websphere за шлюзом. Этот вызов всегда приводил к той же старой ошибке CORS:

No 'Access-Control-Allow-Origin' header is present on the request resource. Origin 'https://test1.domain.com' is therefore not allowed access.

При более внимательном рассмотрении было обнаружено, что Access-Control-* заголовки отсутствуют в ответе, возвращающемся для этого ресурса. Теперь Websphere поставляется с собственным http-сервером, и оказывается, что http-сервер поглощает заголовки управления доступом. Оттуда можно было легко исправить http.conf в websphere.

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

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

Акшай