ym104432846
Вставьте ссылку на видео из Youtube, Rutube, VK видео
Задайте вопрос по видео
Что вас интересует?
00:00:47
Проблемы кросс-доменного запроса:
  • 1. Для ограничения обращения к API планируется разрешить доступ только определённым площадкам (домены типа *my-site.com*)
  • 2. Решено использовать плагин или прослойку в FastAPI для работы с CORS и добавления площадок, которым разрешено обращение к API
  • 3. Получен успешный результат запроса после обновления страницы и включения настроек CORS, теперь отображаются данные отелей
00:04:17
Настройка CORS политики:
  • Разрешено использование домена `api.my-site.com` для обращения к API компании
  • Указаны конкретные параметры конфигурации CORS (Allow-Origin, Allow-Credentials, Allow-methods, Allow-headers), необходимые для взаимодействия фронтенда с бэкендом
  • Обеспечено разрешение отправки cookie и запросов с различных адресов от фронтенда к бэкенду
0: Несмотря на то, что бэкендеру не очень важно глубоко понимать устройство джава, скрипта иль css и то, как написан фронтент, очень важно понимать, как делаются запросы с браузера к нашему апи, ведь все-таки мы отвечаем за то, чтобы наш.
1: Был доступен, и чтобы с ним могли работать те же самые фронтендеры, я написал простенькое приложение на реакте, которое делает всего 1 запрос для очень любопытных. Я его покажу. Здесь буквально 1 запросик делается по нашему.
2: Адресу localhost, 8000 алтай и передаются параметры дейт Фром и day to и далее. Мы просто отображаем эти отели на экране. Так вот, если мы прямо сейчас с текущими настройками попробуем зайти в наше приложение обновить
3: Его и у нас ничего не отобразится. Мы зайдём в сеть, ещё раз обновим страницу, посмотрим, какой запрос делается, делается собственно запрос к local host отели здесь вот написано алтай, дата from data to и вроде код статуса.
4: 200 ок. И даже зелёный свет, но у нас подсвечено красным и написано ошибка корс у нас не даёт браузер отправить запрос к нашему апи, почему? Потому что мы на бэкенде не указали
5: Какие площадки могут обращаться к нам, потому что если любая площадка может обратиться к нашему апи, это создаёт много проблем, и мы не будем обсуждать сегодня, какие проблемы мы можем обсудить это в комментарии, но в
6: В целом очень полезно ограничивать набор площадок, которые могут, я имею ввиду набор сайтов, которые могут обращаться к нашему апи. В идеале обычно у нас есть какой-то домен, например, my сайт точка ком и фронтент у нас крутится на май сайт.
7: Точка ком и backend у нас крутится на api, точка, май сайт, точка ком. И таким образом, у нас все запросы могут приходить только с my сайт точка ком, то есть с этого домена, на котором мы сидим, они не могут прийти с какого-то другого домена с
8: Домена с того, где хотят отправить плохой запрос на наш сайт, мы не разрешаем это за это отвечают корсы ну, корсы вообще cross origin да, между сущностями, между веб сайтами взаимодействия как оно должно быть налажено, что нам
9: Нужно сделать. Нам в фастапи нужно подключить некоторую прослойку, некоторый плагин, не знаю, как его назвать для работы с curse и указать, какие площадки могут к нам обращаться. Давайте это сделаем. Я вставлю код с документации фастапи.
10: Как он там и есть итак 1, что у нас есть это добавление ориджинов, то есть добавление площадок, которые могут обращаться к нашему апи и затем это метод add мидлу, про мидлу мы поговорим.
11: Немножко позже в нашем курсе, но пока просто посмотрим, как это работает. Добавляем мидл эр корс мидл уэр и прописываем некоторые параметры. Корс мы, конечно, импортируем из фастапи и давайте сначала сохраним и посмотрим.
12: Что у нас произошло, а потом уже обсудим, что да, как. Итак, я обновляю страницу. Посмотрим, какой у нас запрос будет. Давайте нажмём сохранить журнал, чтобы у нас остался этот запрос здесь.
13: Смотрите, вот это был старый запрос, это был get запрос, но он был с ошибкой. Сейчас у нас тот же самый get, запрос по тому же самому адресу. Но здесь уже есть кое-что другое. Здесь. Ну, во первых, все отработало у нас.
14: Есть заголовки ответов, которые нам отправляет ювикорн. Есть заголовки запросов, которые мы отправляли, ну, которые браузер автоматически отправляет, да, о том человеке, который сидит, который отправляет запрос. Что здесь интересного, в
15: Ответах приходит от фастапи, что мы разрешили локалхосту 3000 обращаться к нашему апи и также ещё некоторые другие настройки. Мы сейчас про них посмотрим. И в итоге мы получили реально данные. Вот они, вот наши отели.
16: Мы послали данные date from date to вот получили ответ. Собственно, можно его смотреть, разглядывать, и он также отобразился у нас. Естественно, здесь мы прошлись по циклу и также отобразили, как в джиндже мы делали только уже через java script, в чем же дело?
17: Что мы сделали такого, что нам помогло работать с фронтендом и дать доступ конкретно этому домену с нами работать. 1 это параметр allow оридженс. То есть разрешить следующие ориджины. Мы здесь указали просто список из 1 это
18: Может быть список из нескольких доменов если у вас какая-то большая система, много площадок обращаются к 1 и тому же api, у вас там несколько сайтов, например, 1 какой-нибудь лендинговый сайт, другой ещё другой сайт, и они все могут обращаться к 1 апишке далее.
19: Allow креденшелс отвечает за cookie и если стоит true, то с каждым запросом будет посылаться кука, которая у нас есть в записана в куках помните, мы делали аутентификацию, авторизацию и там у нас хранится джт токен в куке и ес.
20: Если, например, здесь будет false, то с фронтенда уже не будут приходить cookie, и мы не сможем распознать, какой клиент к нам пришёл, поэтому обязательно тоже здесь ставим true далее, если мы говорим про продакшн обяза.
21: Обязательно нужно указать, какие методы можно использовать, не просто написать там все, да, вот есть такая звёздочка, которая говорит, что, да, вообще все методы, которые там есть, нет, их нужно прописать конкретно. И тоже самое касается хедеров, нельзя указывать, чтобы, да, мы принимае.
22: Вообще все хедеры вообще шлите что хотите. Нет, мы принимаем конкретно вот набор таких хедеров, например, set cookie, там авторизейшн. Если у нас авторизация через хедеры происходит, и ещё парочка.
23: Хедеров, которые очень помогают и порою прямо спасают ситуацию, потому что иногда фронтент просто отказывается, отказываются отправляться запросы. А с вот такими хедерами они отправляются. Итак, что мы сделали?
24: Мы разрешили фастапи, коммуницировать, мы разрешили, точнее, фронтенду, коммуницировать с нашим фастапи, с нашим бэкендом. И, как я говорил, да, у нас в будущем, потом будет, конечно, какой-нибудь my сайт точка ком уже без порта, он
25: Будет https, конечно, а у нас будет апишка. Вот, например, такая вот такая api, точка, май, сайт, точка, ком. И мы разрешим вот этому домену обращаться к нашей апишке. Таким образом. Все
26: Связь будет налажена, а какой-то другой сайт не сможет обратиться к нашему, к нашей апишке именно через браузер, потому что большинство скама происходит через браузеры. Вряд ли какая-нибудь бабушка сидит на пайтоне и отправляет.
27: Запросы в какой-то api скорее и таким образом переводит деньги, скорее всего, она пользуется каким-то приложением, и большинство людей, которые не знают, как может происходить обман, пользуются браузерами, и поэтому нам нужно очень тщательно поди.
28: Бирать здесь список ориджинов ни в коем случае не писать. Все иначе кто-то может сделать большую неприятность нашему бизнесу. Таким образом, мы поняли, что бэкендер, хоть и отвечает только за написание апи.
29: Тем не менее он должен дать полный доступ фронтендерам, чтобы они могли с ним взаимодействовать, например, отправлять cookie, отправлять запросы с разных адресов, отправлять get post delete patch и прочие запросы и также с какими-то конкретными хедерами уж.