Большинство интерфейсных веб-разработчиков уже сталкивались с тем, что браузер выдает ошибку CORS всякий раз, когда мы хотим отправить запрос AJAX GET или POST на сервер с нашего локального хоста или из какого-либо другого домена.
А если вы являетесь разработчиком Full Stack, бремя разрешения CORS для целей отладки или тестирования лежит на вашей спине, и вам остается искать ресурсы, чтобы понять CORS и заставить его работать с сервером. Итак, давайте разберемся, что происходит во время запроса CORS REST.
Браузер вызывает функцию безопасности CORS, когда ваш JavaScript находится на сервере, отличном от места развертывания внутреннего кода. Например, у вас бэкэнд (php / django | flask / java), который удовлетворяет запрос REST, если он находится в другом домене или на другом сервере в том же домене (сервер узла, отображающий ваш интерфейс, и Tomcat / Apache, отображающий ваши Rest API). Вот почему это называется совместным использованием ресурсов с перекрестным происхождением. Это означает, что происхождение ваших backend API и frontend javascript не совпадает.
Теперь давайте разберемся, что происходит, когда браузер обнаруживает CORS.
Предположим, вы хотите отправить запрос POST по URL-адресу http://xyz.com:8080/Sdp/api/public/auth, где вы хотите авторизовать пользователя для входа в систему, где учетные данные, необходимые для публикации запроса, - это имя пользователя. и пароль, который вы хотите поместить в тело запроса POST в формате json. Теперь для этого вы хотите установить content-type: application / json в заголовке запроса POST, чтобы сервер мог распознавать контент, поступающий в тело, и действовать соответствующим образом.
Теперь мы ожидаем, что один запрос POST попадет на сервер и отправит нам тело ответа, в котором указывается, правильный запрос или нет, но этого не происходит с браузером.
Как только ваш браузер распознает, что запрос является кросс-источником, он разбивает ваш простой запрос POST на следующие части: -
1. Запрос OPTIONS отправляется на сервер, который спрашивает сервер, разрешены ли на сервере определенный заголовок и запрос Cross Origin, и ожидает его ответа.
2. Если сервер отправляет ответ 200 со списком заголовков запросов, разрешенных сервером.
3. Если заголовок, который вы хотите установить, не разрешен сервером, запрос GET / POST будет отменен.
4. Если заголовок, который мы хотим установить, разрешен, запрос GET / POST будет отправлен на следующем шаге.
Взгляните, например, на следующее изображение: -
На изображении выше для запроса POST к BASE_URL / Sdp / api / public / auth сначала отправляется запрос OPTIONS, а затем отправляется запрос POST.
То же самое и с запросом GET BASE_URL / Sdp / api / secure / echo / Андрей
Сначала отправляются параметры, а затем отправляется GET.
Теперь давайте разберемся, что происходит в OPTIONS
Как я уже говорил вам выше, для установки заголовка content-type: application / json в запросе POST браузер спрашивает сервер, позволяет ли он устанавливать тип содержимого, как вы можете видеть на изображении, которое он устанавливает Access-Control-Request-Headers. Итак, если вы хотите, чтобы этот запрос POST работал в CROSS-источнике для каждого запроса OPTIONS, вам необходимо отправить ответ, который заголовок, какие методы и перекрестное происхождение разрешены или нет. Посмотрите на заголовок ответа на изображении выше. Поле Access-Control-Allow-Headers, Access-Control-Allow-Methods и Access-Control-Allow-Origin - это ответ моего сервера. Это называется предполетным запросом и ответом. Теперь, когда браузер проверяет, что то, что мы пытаемся установить, разрешено сервером, он отправляет основной запрос POST, который мы ожидали.
Теперь вы могли видеть, как заголовок Content-type установлен на желаемое значение.
Теперь посмотрим на другой пример, в котором я пытаюсь установить значение заголовка x-auth-token и content-type в запросе GET.
Что произойдет, если сервер не отправит предполетный ответ, в котором разрешен какой-либо заголовок или источник?
Ваш основной запрос POST или GET не будет отправлен с сообщением об ошибке CORS в консоли браузера, которую мы всегда получаем.
В следующем блоге я расскажу, как включить CORS в Spring framework в java.