Кроссдоменные запросы (CORS)

Использование Origin-заголовков для возможности из JavaScript осуществлять Ajax-запросы к API на другом домене.

  • 00:00:22 - HTTP
  • 00:00:52 - GET/HTTP
  • 00:01:11 - script
  • 00:02:03 - Blocked by CORS policy
  • 00:02:37 - Same Origin Policy
  • 00:03:08 - Cross Origin
  • 00:05:01 - Same Origin
  • 00:05:22 - Same Origin Policy
  • 00:06:50 - Примеры работы
  • 00:07:42 - Methods and Headers
  • 00:11:56 - Simple Request
  • 00:12:22 - GET + Accept
  • 00:13:47 - Access-Control-Allow-Origin
  • 00:14:44 - POST
  • 00:15:50 - POST в формате JSON
  • 00:16:51 - Preflighted Request
  • 00:17:01 - Предзапрос OPTIONS
  • 00:18:21 - Access-Control-Allow-Methods
  • 00:19:36 - Access-Control-Request-Headers
  • 00:20:11 - Access-Control-Allow-Headers
  • 00:21:10 - Access-Control-Request-Methods
  • 00:24:23 - Extended Headers
  • 00:24:27 - X-Version
  • 00:25:23 - Authorization
  • 00:26:47 - Cookies
  • 00:27:30 - Access-Control-Allow-Credentials
  • 00:27:55 - Access-Control-Allow-Origin
  • 00:28:41 - Other
  • 00:29:18 - Expose Headers
  • 00:31:14 - Max Age
  • 00:32:08 - Подведение итогов
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Комментарии (13)
А

Полезное видео.

Ответить
Алексей Тимков

просто прекрасный материал. Очень доступно и ничего лишнего

Ответить
fedot

Спасибо, JSONP жаль не рассмотрен.

Ответить
Артем

Фантастика! Сколько полезной информации. Тема кроссдоменных запросов мне съела столько времени и нервов в своё время, что теперь я всякий раз отказываюсь от этого. Теперь не буду. На счёт Access-Control-Allow-Credentials, Google Chrome с марта 2020 по умолчанию запрещает передачу куков на чужие хосты, и это правится только настройками в браузере.

Ответить
slo_nik

Добрый день.

Дмитрий, обращаюсь к Вам как к последней инстанции))) Возникла ситуация в работе сайта, как раз с политикой CORS.

Есть некий сайт, работает на prestashop v.1.6, через установленный плагин получает/отдаёт данные для другого сайта, prom.ua.

Ситуация сложилась такая.

В офисе есть три компьютера. На одном из трёх этот плагин работает без проблем, а на двух других постоянно ошибка CORS.

Проверяли на домашних компьютерах. При заходе на сайт с одного - всё работает, с другого нет.

Проверяли с мобильных телефонов, ситуация такая же. С одних работает, с других нет.

Сначала грешили на плагин и сервер. Но если бы была проблема в плагине или сервере, то не работало бы везде.

Проблема с настройками роутера, windows?.. Service Worker-ы проверял, для сайта не используются, только для prom.ua ставится SW.

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

Ответить
Дмитрий Елисеев

Там вроде ответили, что проблема в обращении к http адресу вместо https.

Ответить
slo_nik

Да, но загадка в том, что с других устройств всё работает, ошибки CORS нет.

Почему на двух компьютерах идёт обращение через http, а на одном как и положено, через https?

Все компьютеры подключены к одной сети.

С телефонами такая же фигня, с одних работает, с других нет.

И вот где искать причину - непонятно.

Ответить
slo_nik

Тут уже предполагаем, что возможно причина в настройках роутера или в самих системах. К кэше dns или ещё в чём-то.

Другое дело если бы не работало везде, тогда понятно. Проверка настроек сервера, проверка кода плагина, проверка js скриптов, которые отправляют запрос.

А так непонятно, куда бежать, куда стрелять!

Ответить
Михаил

Спасибо! Нигде не мог найти информацию, почему имено get и особенно post являются безопасными.

Ответить
Дмитрий Елисеев

Об этом рассказано во втором эпизоде.

Ответить
Иван Сковпин

Правильно ли я понял, что в случае в Simple Request браузер всегда посылает запрос, но может не вернуть ответ обратно в JavaScript, если Allow Origin и Origin не совпадают? Тогда ведь получается, что в браузере у пользователя можно выполнить код, который будет спамить любой сайт/API запросами, просто не получая на них ответы. Или есть ещё какие-то нюансы, чтобы избежать подобного сценария?

Ответить
Дмитрий Елисеев

Да, простые GET-запросы на чтение и POST запросы в формате www-form-urlencoded может выполнить в любом случае.

Для борьбы с таким POST-спамом на сайтах как раз придумана CSRF-защита форм, когда в них добавляют hidden-поле со случайным токеном, одновременно возвращаемым в Set-Cookie. Тогда если JavaScript и загрузит форму с токеном по GET, то при отправке данных уже не сможет отправить POST-запрос с заголовком Cookie, так как он не подпадает под Simple Request.

А в API можно сделать работу только по JSON и выдавать доступ клиентам через Oauth2 по client_id. И уже каждому клиенту возвращать его домен в Allow-Origin. Тогда никакие анонимные запросы не пройдут.

Ответить
Галина

Спасибо за видео!)

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu