За вчера и за сегодня пересмотрел тонну видосов на эту тему. Только этот помог по настоящему разобраться в теме и решить проблему. Сегодня я нашел ответы на те вопросы, которые даже не знал как гуглить. Константин, если читаете, огромное вам спасибо. Ни в коем случае не забрасывайте канал.
Крутое видео, вроде проста тема и потому лень было изучать, но всё-таки тут есть некоторые моменты который в которые надо вникнуть, потому видео полезное
Супер, отличное видео, то что я искал! Читал официальную докумментацию, было как-то трудно её воспринимать, в вашем видео всё наглядно и понятно, спасибо за годный контентыч
Спасибо, очень понятное объяснение и примеры хорошие. Единственное пожелание это улучшить произношение терминов на английском языке). Удачи в развитии.
Привет подскажите пж, например на сайте, идет прямая трансляция, ну во всяком случае так должно быть) а можно определить, запись это, или трансляция? заранее спс
Добрый день! А почему при запросе со стандартным значением для 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
Не пойму чем тогда 'HTTP_ORIGIN" отличается от * если у всех фронтов реквестов есть эти ориджины, то чем же тогда сужается диапазон допуска ? В чем отличие ?
Не пойму кто в опасности тогда без механизма корс ? клиент получается ? то есть кросссайт может получить данные моих куков для оридижна получается так ? Или наоборот якобы 8080 в потенциальной опасности что к нему лезу из 8000 ? - не пойму в чем для него тогда опсасность ..
к сожалению да реальный опыт суть сводится к тому что решили собирать в "последний день" перед релизом и когда запускали именно тут и возникли ошибки cors, раньше их не было. поэтому решение принимали максимально быстро :) девопс уже успел нагуглить решение дополнив nginx.conf костыльными заголовками и задеплоив это.
Добрый день, скажите пожалуйста а вы создавали куку на клиенте или на сервере-апи, к которому клиент-браузер обращается? Вообще как создавали куку? Дело в том я выставил все заголовки,настройки 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. Ну ладно это так история, может кто читать будет и на мои грабли не нарвется.
Спасибо за видео, очень понравилось, что детально и с примерами ❤ Если еще произношение английских слов подтянете, вообще шикарно будет. А то Валуе вместо вэлью (value) чет режет уши))
@@laticalamonzi2814 тут надо подумать каких целей охото добиться пользователи сайт не будут видеть в приватных сетях, они будут его видеть на продакшене, значит PNA их не коснется и им заголовок не нужен. разработчику PNA можно отключить с помощью флагов в браузере или с помощью расширений отключающих CORS ну либо в локалке отправлять новый заголовок поэтому PNA в большей степени касается разработчика
За потраченное время автору уважение и большое спасибо.
За вчера и за сегодня пересмотрел тонну видосов на эту тему. Только этот помог по настоящему разобраться в теме и решить проблему. Сегодня я нашел ответы на те вопросы, которые даже не знал как гуглить. Константин, если читаете, огромное вам спасибо. Ни в коем случае не забрасывайте канал.
он же вроде Евгений "валуе" Кувшинов😁
Красавчик. Все по делу и с тонкостями реализации
Для меня, как новичка в области CORS - видео просто потрясающее) Спасибо!
Очень качественное, крутое видео!! Для меня тема CORS раскрыта! Объяснение - вышка! Автору - респект!
Подача материала, примеры, изложение, все на уровне. Благодарность выражаю.
Крутое видео, вроде проста тема и потому лень было изучать, но всё-таки тут есть некоторые моменты который в которые надо вникнуть, потому видео полезное
Супер, отличное видео, то что я искал! Читал официальную докумментацию, было как-то трудно её воспринимать, в вашем видео всё наглядно и понятно, спасибо за годный контентыч
Спасибо, все сжато, и по делу... 👍
Автор, огромнейшее спасибо за видео - мало того что разложил все по полочкам, но еще и написал middleware, который можно использовать. Респект
Толковое видео. Благодарю!
Спасибо, очень понятное объяснение и примеры хорошие. Единственное пожелание это улучшить произношение терминов на английском языке). Удачи в развитии.
учту, буду произносить нормально термины
Евгений, спасибо большое! Это самый наглядный материал по этой теме который я только встречал
Спасибо за контент, подкрепил знания
Самое лучшее и понятное объяснение очень сложной темы, большое спасибо!
Спасибо огромнейшее!!!! Дико выручил и шикарно объяснил🤩
Молодец!, очень просто и классно все рассказал!
Огромное спасибо! CORS я использовал, но понимание самого механизма наступило только сейчас
спасибо за донат
С меня подписка и лайк. Без воды. Качественно ☺
очень классное объяснение, спасибо автору!
Отличное видео! Странно, что там мало лайков и просмотров. Автор большой молодец
Мне бы это видео лет 6 назад... Эх, столько бы «боли» прошло мимо))
Спасибо, отличный выпуск.
Огромная благодарность автору видео. Ваше время не было потрачено зря!
Супер видос! Очень полезно. Только еще замечу что в ларавел есть встроенный механизм coors. C 7 версии вроде.
да хотел об этом механизме рассказать
но случайно показал как он устроен (он как раз через middleware работает)
спасибо за видео . Очень понятно обьяснил
Очень круто. Спасибо!
хорошее видео без воды, спасибо
Спасибо большое! Очень полезное видео!!!
а еще htp, вот это действительно много нового узнал
Привет подскажите пж, например на сайте, идет прямая трансляция, ну во всяком случае так должно быть) а можно определить, запись это, или трансляция? заранее спс
Очень хорошее объяснение темы
Добрый день! А почему при запросе со стандартным значением для 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
Все по делу. реально помог!
Большое спасибо. Помог очень
Спасибо, очень полезно!!!
огромное спасибо автору. Самый полный и понятный материал который я смог для себя найти на просторах интернета на русском языке )
Не пойму чем тогда 'HTTP_ORIGIN" отличается от * если у всех фронтов реквестов есть эти ориджины, то чем же тогда сужается диапазон допуска ? В чем отличие ?
HTTP_ORIGIN это в PHP в действительности он берет из запроса заголовок Origin который проставляет браузер поддерживающий cors.
Не пойму кто в опасности тогда без механизма корс ? клиент получается ? то есть кросссайт может получить данные моих куков для оридижна получается так ? Или наоборот якобы 8080 в потенциальной опасности что к нему лезу из 8000 ? - не пойму в чем для него тогда опсасность ..
в опасности данные клиенты на стороннем ресурсе могли бы быть
в современных сайтах не только куки используются, но если бы использовались только они.
@@kuvshinovee Ааа , понятно )) Плохой сайт это сам ориджин - 8080 , а 8000 это типо "банк" . Вот гад такой !
Спасибо за видеоурок, у меня такая проблема, например если апи вернет ошибку, то тогда выведется cors errors,а если 200 все норм,как можно решить ?
скорей всего при ошибках не проставляются заголовки, отсюда и cors error
А пример из 27:00 прямо из реального опыта? Прямо диковато выглядит когда в команде есть девопс, а коммуникации между фронтои и беком никакого.
к сожалению да реальный опыт
суть сводится к тому что решили собирать в "последний день" перед релизом и когда запускали именно тут и возникли ошибки cors, раньше их не было.
поэтому решение принимали максимально быстро :)
девопс уже успел нагуглить решение дополнив nginx.conf костыльными заголовками и задеплоив это.
Спасибо, большое
Добрый день, скажите пожалуйста а вы создавали куку на клиенте или на сервере-апи, к которому клиент-браузер обращается? Вообще как создавали куку? Дело в том я выставил все заголовки,настройки 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. Ну ладно это так история, может кто читать будет и на мои грабли не нарвется.
top
htpp, хм....
интересный протокол, никогда не слышал😁
Зачет
большое спасрбо
Спасибо за видео, очень понравилось, что детально и с примерами ❤
Если еще произношение английских слов подтянете, вообще шикарно будет. А то Валуе вместо вэлью (value) чет режет уши))
Грааль
метод path ? не смотря на оговорки большое спасибо автору
Спасибо, видео очень полезное
Видео хорошее, информативное.
Но есть масса оговорок.
В том числе неплохо бы научиться читать английский и хотя бы перестать "патч" называть "пафом".
пиф паф
А как консоль разработчика в хроме перевести на русский?
export LANG=ru_RU.UTF-8
chromium
Можете еще по теме кэша сделать объемлющее видео ?? Такую тему раскусили , а ту и подавно смогёте .. И еще по бы по аутентификации )
по аутентификации и авторизации есть в планах, но позже
Нужен курс по Laravel!!!!!
врятли он будет, не представляю что можно рассказать чего нет в документации.
Я реально заснул на 20 минуте
...и, внезапно, CORS PNA =(
PNA пришло в хроме 98 версии в качестве эксперимента и на момент записи видео я ещё с ним не сталкивался, но да полезно было бы добавить про это
@@kuvshinovee я поняла, поэтому и поставила грустный смайлик. выхода, вроде бы всего два: https и Access-Control-Allow-Private-Network:true...
@@laticalamonzi2814 тут надо подумать каких целей охото добиться
пользователи сайт не будут видеть в приватных сетях, они будут его видеть на продакшене, значит PNA их не коснется и им заголовок не нужен.
разработчику PNA можно отключить с помощью флагов в браузере или с помощью расширений отключающих CORS ну либо в локалке отправлять новый заголовок
поэтому PNA в большей степени касается разработчика
@@kuvshinovee да, да, вот нас-то, в основном, и касается =)
Почему PATCH это паф а не пэтч?
неправильно произносил, но по видео ряду понятно о чем идет речь
С английским, конечно, у тебя бедулька.. а так вроде много что по делу...
Bhai hindi bhasha me video bana le 😂
Полезная инфа, спасибо👍👍