Здравствуйте! Спасибо огромнейшее за такое комфортное объяснение и кучу полезной информации (теории и даже тренажер) Впервые встретила на столько доступную информацию на эту тему))
Захеширлванный пароль можно получить обратно в исходный, если иметь доступ к секретному ключу, по которому произошло преобразование и знать какой тип алгоритма использовался для хеширования
Привет) от 29 тысяч. Подробно можно изучить на сайте школы: qa.studio/. Там-же есть кнопка «Написать» - так быстрее можно получить ответы, чем в комментариях ютуба
При использовании сессий можно дополнительно проверять user agent пользователя, и IP address, даже если каким то чудом угонят куки, то злоумышленник не сможет получить доступ к сайту никак, так как валидирабтся данные не только от сессионной куки, но и дополнительные данные ⚖️.
полезная нагрузка и хедеры jwt кодируется с помощью секретного ключа и сверяется с той подписью, что указана в присланом jwt. Если подписи совпали, значит токен 'настоящий' и тот сервис, что генерировал этот jwt тоже знал этот секретный ключ. При этом сам секретный ключ не нужно хранить в бд.
В словарике неверное определение. Хеширование не один из способов шифрования. Это разные понятия. Хэширование обладает свойством односторонности и применяется для проверки. Шифрование же представляет двусторонний процесс преобразования данных с возможностью их расшифровки.
Вставлять этот "Bearer", а на самом бэкенде потом вырезать его, чтобы проверять токен. Верх идиотизма, не использовал эту дебильную приставку и не буду. Может она имеет какой то смысл, если по какой то причине у приложения множество способов авторизации, но если способ один - JWT, то нахрена тащить этот идиотский синтаксис со "схемой" мне не понятно.
А еще верх идиотизма разные методы, типа GET, POST, DELETE и т.д. использовать, т.к. потом приходится их по-разному обрабатывать. Проще везде один метод использовать, можно даже свой запилить, например, 'Q', чтобы трафик сэкономить и в логах будет компактно смотреться
@@Андрей-ф5е6н не передергивай, методы get pust put update активно используются, в то время как большинство приложений используют какой то один метод аутентификации - либо сессии, либо jwt, и в большинстве случаев никакого смысла в "Bearer" перед токеном нет, ибо это слово просто банально вырезается без всяких проверок на тип аутентификации и берётся сам токен.
Очень круто объясняешь, сложную информацию, простыми словами, огромный респект!
Здравствуйте!
Спасибо огромнейшее за такое комфортное объяснение и кучу полезной информации (теории и даже тренажер)
Впервые встретила на столько доступную информацию на эту тему))
Теперь нужно отдельное видео про "Покемоны"! Спасибо огромное за такое понятное объяснение!
У Вас талант объяснять сложные вещи простым языком) огромное спасибо за Ваши лекции 🙏🏽
Одна из самых крутых показательных лекций, большое спасибо! 👏🔥
Самое понятное объяснение про jwt, которое я когда либо встречала. Спасибо ☺️
Супер полезный урок! Благодарю!
А есть ссылочка на Миро со всеми подсказами? Очень красиво и структурировано выглядит
спасибо, Герман. классное познавательное видео
super poleznoe video!!!!!!
Захеширлванный пароль можно получить обратно в исходный, если иметь доступ к секретному ключу, по которому произошло преобразование и знать какой тип алгоритма использовался для хеширования
Спсибо за ваши ролики очень хорошо обясняется и подскажите пожалуйста где можно посмотреть на miro который вы показываете ? очень интересно.
Очень классное видео и для тестировщиков, но, пожалуйста, уберите фоновую музыку, очень мешает, особенно при ускоренном просмотре. 😢
13:16 вопрос - а если куки были украдены, в этом случае злоумышленник получается сможет авторизоваться. Как быть? Http only cookies спасет?
Сколько стоит обучение.
Привет) от 29 тысяч. Подробно можно изучить на сайте школы: qa.studio/.
Там-же есть кнопка «Написать» - так быстрее можно получить ответы, чем в комментариях ютуба
Когда пошло объяснение на примерах, сразу захотела купить курс.
Пошла смотреть по ссылке
Здравствуйте! Эта информация предоставляется в рамках курса Тренажёр по API «Битва покемонов» с лекциями (степик)?
Нет. На степике мы работаем с покемонами. Там авторизация работает на API токенах. Там свои отдельные лекции
При использовании сессий можно дополнительно проверять user agent пользователя, и IP address, даже если каким то чудом угонят куки, то злоумышленник не сможет получить доступ к сайту никак, так как валидирабтся данные не только от сессионной куки, но и дополнительные данные ⚖️.
Где лучше хранить access и refresh token? В localStorage или cookie и почему?
Не берусь за правду в последней инстанции, но выбрал бы куки с флагом HttpOnly
habr.com/ru/articles/143259/
Не правда, что при jwt не надо лезть в базу - как вы валидировать подпись то будете?
jwt не панацея
полезная нагрузка и хедеры jwt кодируется с помощью секретного ключа и сверяется с той подписью, что указана в присланом jwt. Если подписи совпали, значит токен 'настоящий' и тот сервис, что генерировал этот jwt тоже знал этот секретный ключ. При этом сам секретный ключ не нужно хранить в бд.
В словарике неверное определение.
Хеширование не один из способов шифрования. Это разные понятия. Хэширование обладает свойством односторонности и применяется для проверки. Шифрование же представляет двусторонний процесс преобразования данных с возможностью их расшифровки.
В словаре вот прямо дословно это-же и написано: buildin.ai/qa-studio/share/98067156-7170-41b5-ad6d-c125cc5c4aa8
Вставлять этот "Bearer", а на самом бэкенде потом вырезать его, чтобы проверять токен. Верх идиотизма, не использовал эту дебильную приставку и не буду. Может она имеет какой то смысл, если по какой то причине у приложения множество способов авторизации, но если способ один - JWT, то нахрена тащить этот идиотский синтаксис со "схемой" мне не понятно.
А еще верх идиотизма разные методы, типа GET, POST, DELETE и т.д. использовать, т.к. потом приходится их по-разному обрабатывать. Проще везде один метод использовать, можно даже свой запилить, например, 'Q', чтобы трафик сэкономить и в логах будет компактно смотреться
@@Андрей-ф5е6н не передергивай, методы get pust put update активно используются, в то время как большинство приложений используют какой то один метод аутентификации - либо сессии, либо jwt, и в большинстве случаев никакого смысла в "Bearer" перед токеном нет, ибо это слово просто банально вырезается без всяких проверок на тип аутентификации и берётся сам токен.