Супер, отличное видео, то что я искал! Читал официальную докумментацию, было как-то трудно её воспринимать, в вашем видео всё наглядно и понятно, спасибо за годный контентыч
За вчера и за сегодня пересмотрел тонну видосов на эту тему. Только этот помог по настоящему разобраться в теме и решить проблему. Сегодня я нашел ответы на те вопросы, которые даже не знал как гуглить. Константин, если читаете, огромное вам спасибо. Ни в коем случае не забрасывайте канал.
Спасибо, очень понятное объяснение и примеры хорошие. Единственное пожелание это улучшить произношение терминов на английском языке). Удачи в развитии.
к сожалению да реальный опыт суть сводится к тому что решили собирать в "последний день" перед релизом и когда запускали именно тут и возникли ошибки cors, раньше их не было. поэтому решение принимали максимально быстро :) девопс уже успел нагуглить решение дополнив nginx.conf костыльными заголовками и задеплоив это.
Спасибо за видео, очень понравилось, что детально и с примерами ❤ Если еще произношение английских слов подтянете, вообще шикарно будет. А то Валуе вместо вэлью (value) чет режет уши))
Привет подскажите пж, например на сайте, идет прямая трансляция, ну во всяком случае так должно быть) а можно определить, запись это, или трансляция? заранее спс
Не пойму кто в опасности тогда без механизма корс ? клиент получается ? то есть кросссайт может получить данные моих куков для оридижна получается так ? Или наоборот якобы 8080 в потенциальной опасности что к нему лезу из 8000 ? - не пойму в чем для него тогда опсасность ..
Не пойму чем тогда 'HTTP_ORIGIN" отличается от * если у всех фронтов реквестов есть эти ориджины, то чем же тогда сужается диапазон допуска ? В чем отличие ?
Добрый день! А почему при запросе со стандартным значением для Content-Type: application/json на 18:26 предварительный запрос происходит, а на 20:30 с использованием Content-Type: multipart/form-data его нет? Как и с text/plain. Это какое-то исключение для значения application/json/? И второй момент, на 20:50 меняется значение заголовка на text/plain1,но на стороне сервера определен заголовок application/json, а запрос все равно считается успешным, почему?
я в видео объяснил, да это исключение, но это исключение не для application/json если отсылается post запрос и там передаются только определенные заголовки вроде (Accept, Accept-Language, Content-Language с любыми значениями или Content-Type со значениями multipart/form-data или text/plain и тд в видео я перечислил) то в таких случаях не отправляются предварительные запросы с OPTIONS так как запрос считается "стандартным" что касается 20:50 то я ставлю значение Content-Type: text/plain1 это НЕ СТАНДАРТНОЕ значение и браузер отправляет запрос с OPTIONS чтобы проверить можно ли так обращаться и сервер ответил что Content-Type присылать можно, все это хорошо видно на 20:57
Добрый день, скажите пожалуйста а вы создавали куку на клиенте или на сервере-апи, к которому клиент-браузер обращается? Вообще как создавали куку? Дело в том я выставил все заголовки,настройки credentials в положительно и на сервере и в fetch на клиенте, создаю куку коде на сервере, прописывая там в php setcookie('name','value', time()+600)). Затем с клиента делаю fetch на адрес сервера-апи (там пара строк кода где указаны нужные заголовки и код создания куки вышеуказанный). И ничего не происходит. Кука так и не передается в заголовках запроса. Как именно создать куку чтобы она передавалась, где ее создавать в коде на сервере-апи, или в коде js на клиенте? Можете подробно описать механизм пожалуйста.
Я создавал куку на клиенте, в браузере или через консоль или через плагин для управления куками сайта (для сайта api.localhost:8000). я думаю у вас небольшое непонимание того как работают куки и рассказывать это в комментарии ну такое себе, попробуем. браузер при заходе на сайт по "url" определяет какие куки ему слать, например если ты заходишь на example.com то он собирает один список кук в запросе, когда ты с этого сайта делаешь запрос на api.example.com тут список кук может быть другим. Установка куки возможно только до того момента пока не стал отправлять html body. Дополнительно у кук есть еще такое понятие как secure и httponly (в твоем случае оба варианта false), еще не забывай о домене и path Если у тебя api.example.com устанавливает куку, то при заходе на example.com ты ее видеть не будешь, ты ее сможешь видеть если сделаешь http запрос на api.example.com (как я это сделал я открывал один сайт localhost:8080 а уже внутри него делал запрос на api.localhost:8000 и вот у второго запроса отправлялась куки только в том случае если я указывал credentials: 'include' и при этом api.localhost:8000 возвращало заголовок CORS РАЗРЕШАЮЩИЙ обращаться сюда с куками)
мой простой совет зайдите туда где должна устанавливаться кука запустите отладчик и посмотрите какие куки вам установлены, на какой срок, какой домен и path и после поробуйте обновить страницу чтобы убедиться что куки отсылаются. ну и как я говорил отправка http заголовков (cookie это http заголовок по сути) возможна только до момента отправки http body
@@kuvshinovee Странно вчера ответил, два раза и комментарий так мой и не появился. На всякий случай уточню у вас еще раз. Спасибо за ответ! Вопрос как у вас межсайтовые куки работали без установленных атрибутов SameSite = None и Secure?
@@konstantinMonty да я видел текст в уведомление на почте, но не видел комментарий под видео, думал удалил автор за не актуальностью. По поводу как они работали SameSite надо проставлять в хроме и его производных начиная с 80 версии и только в случае если куки вы ставите в апихе. В виде куку я ставил через плагин для управления кусками в браузере(оно не требует установки атрибута, просто момент установки куки я не показывал) поэтому оно работало На тему SameSite у как возможно стоит сделать отдельное видео как и про работу с куками
@@kuvshinovee Ну хорошо что уведомление о тесте видели, видимо ютуб не пропускает текст с кусками кода, хотя я даже экранировать их пытался....И даже видел что коммент остался, а потом захожу раз и нету. Если по теме: С samesite выходит огромная ж...чтобы протестировать взаимодействие своего локального сайта со своим локальным апи, когда локальному сайту нужно отсылать куку на локальный апи, то это можно сделать только по https, то есть на локалке нужно как то настроить https у обоих хостов локального сайта и апи. Или только у хоста апи...в общем если будет возможность пожалуйста сделайте видео насчет такого взаимодействия...я 4 дня ковырялся, мне нужно было отправить на апи с своего сайта куку приписанную не к апи, а к сайту, в которой находиться id сессии чтобы апи скушало id сессии из этой куки и выдало обработав этот id данные пользователя. Но как отправить куку на апи, если эта кука задается не самим апи, а сайтом и тут меня постиг крах. А потом еще и эти SameSite = None и Secure с его https....В общем сейчас стараюсь придумать чтобы id сессии передавался в заголовке authorization. Ну ладно это так история, может кто читать будет и на мои грабли не нарвется.
@@laticalamonzi2814 тут надо подумать каких целей охото добиться пользователи сайт не будут видеть в приватных сетях, они будут его видеть на продакшене, значит PNA их не коснется и им заголовок не нужен. разработчику PNA можно отключить с помощью флагов в браузере или с помощью расширений отключающих CORS ну либо в локалке отправлять новый заголовок поэтому PNA в большей степени касается разработчика
