Отличное объяснение, как обычно 👍 для полной картины - было бы хорошо ещё пример, как это всё увязать с фронтом (почти всегда у новичков - это следующий запрос в Гугл) 😅
куча объяснений в интернете, попробую описать кратенько. С клиента отправляется запрос с токеном в заголовках, на бекенде мы смотрим в него и проверяем токен через метод библиотеки. Если токен протух тут два пути - перехватывать на сервере или через клиент, то есть отбработать механизм отправки запроса на рефреш токена, который возьмет его уже из куков нашего клиента. Этот токен тоже нужно проверить на срок годности и валидность соответственно, (плюсом дополнительные проверки, если имеются в базе данных и поиск токена и юзера с ним в БД). Если все ок то отдаешь новую пару токенов и ставишь их в куки клиента. Если на каком-то из этапов провал в ошибку - то выход из сессии
Можно ли использовать рефреш токен как jwt? А в jwt написать под каким id хранится в базе токен и изменять его если не истёк exp. И Я так понимаю у вас в приложении можно иметь только одну сессию, пока не обновится рефреш.
Я не понял одного момента. Для реализации авторизации/аутентификации мы можем использовать токены или сесии. а здесь ты одно и другое слил вместе. так норм делать?
есть подписчики которые не понимают назначения jwt и советуют куки:) напомню что назначение jwt для архитектуры распределённых серверов которым надо всеголишь раздать секрет-ключ-подписи и не заморачиваться с общим хранилищем сессий для всех микросервисов.
Может переставить микрофон в другое место и под другим углом? шум мака 24/7))да и к тому же видно, что ты никогда не говоришь в микрофон. Как по мне хотябы просто повернуть в права так как ты сидишь и чуть вверх. И что-то со звуком в принципе будто-то глухо и объемно, на микро вроде должны быть режимы как брать звук направленно, либо повсюду и т.д
Ты так молодым и не объяснил зачем подписи. Сайты использующие сессии классические, при каждом запросе дергают из базы данных модель пользователя. jwt же позволяет от этого отказаться, ведь в 99% случаев дергают юзера просто чтобы узнать его id для дальнейших манипуляций)))
Чтобы при каждом запросе не обращаться к базе данных за дополнительной информацией о пользователе, например за его ролью. Используя jwt мы можем хранить информацию о пользователе в токене, соответственно в middleware мы можем сразу достать эту информацию, не обращаясь при этом к БД. Если информацию подделают - токен станет недействительным. Благодаря refresh токенам мы обращаемся к БД лишь раз в 15 минут, вместо того, чтобы обращаться к ней при каждом запросе. Да, это немного сложнее, чем просто из БД нужную инфу доставать. Но мы ведь в go приходим за производительностью, правильно ?
@@Aaaa-jn4bm это может и работает хорошо в микросервисах, при общении между ними. Но для обычного сайта это только лишний геморрой. Например, если открыли 2 вкладки браузера, то уже нужно синхронизировать между ними эти токены Да и часто бывает, что id пользователя мало, и приходится его все равно из базы тянуть.
@@sackeja , так для обычного сайта токены в http only куки должны сохранятся, и никакие вкладки тогда синхронизировать не нужно будет :) И приведите пожалуйста пример такой информации, которую придётся тянуть из базы, вместо того чтобы поместить её в токен)) Никто так не делает, jwt именно для этого и создавалось - хранить информацию в токене, чтобы каждый раз не обращаться в бд
Здравствуй! Добавляйся в Slack-комьюнити проекта Creatly - join.slack.com/t/creatlyworkspace/shared_invite/zt-10exogwme-IPDg1bFaH~RfAKYCY~~z8g Там мы можем пообщаться, а в скором времени я скину список задач, которые можно делать
так ты же переизобрел сессии... все это ради меты о юзере в токене? я бы с таким успехом заюзал редис. клал бы инфу о юзере в формате {сессия: мета_юзера} и все. а сами сессии в базе. в кеш закидывать на часов 12, чтоб базу не мучить лишний раз. еще очень интересно почему выбор пал на нереляционную базу, потому как модель данных напротив - реляционная(если я правильно понял). спасибо за видео и старания.
Не совсем. При получении токена я не обращаюсь ни к какому внешнему хранилищу (БД или Редис), а вся нужная информация хранится в токене. Изначально я проектировал модель данных под реляционную БД, но решил взять Mongo. 1) С точки зрения инфраструктуры это дешевле на начале (На MongoDB Atlas можно развернуть монгу в облаке и использовать ее бесплатно до 512 мб, что мне сейчас очень подходит). Я решил что не хочу самостоятельно разворачивать БД и админить ее, проще немного доплатить за DBaaS и спокойно спать по ночам. 2) Поскольку мой проект - стартап, модель данных будет неизбежно изменятся и обновляться. Специфика монги позволяет легко вносить изменения и не морочить себе голову с миграциями в SQL. 3) Я последний раз работал с монго почти 3 года назад, и тот проект имел плохую архитектуру. Решил что хочу попробовать поработать с ней еще раз уже самостоятельно на своем проекте и познакомиться с ней лучше на практике)
На кой черт так все слишком усложнять? при авторизации ты генерируешь некий уникальный строковый идентификатор и передаешь пользователю - теперь это твоя кука. По этой куке ты узнаешь в своей таблице авторизованных пользователей, кто есть кто. ВСЕ.
Чтобы при каждом запросе не обращаться к базе данных за дополнительной информацией о пользователе, например за его ролью. Используя jwt мы можем хранить информацию о пользователе в токене, соответственно в middleware мы можем сразу достать эту информацию, не обращаясь при этом к БД. Если информацию подделают - токен станет недействительным. Благодаря refresh токенам мы обращаемся к БД лишь раз в 15 минут, вместо того, чтобы обращаться к ней при каждом запросе. Да, это немного сложнее, чем просто из БД нужную инфу доставать. Но мы ведь в go приходим за производительностью, правильно ?
Отличное объяснение, как обычно 👍 для полной картины - было бы хорошо ещё пример, как это всё увязать с фронтом (почти всегда у новичков - это следующий запрос в Гугл) 😅
удалось найти?)
Отличный пример!!!
Спасибо Вам большое.
Ждем еще
Жаль что лайк можно поставить только 1. Твой канал рекомендую людям только потому что все на практике показываешь. Это тебя выделяет на фоне остальных
Вот это я великолепный канал отрыл на ночь глядя, повезло)
подписался
Приятно читать, спасибо!
Спасибо Вам большое 🤍
Спасибо большое за видео. Многое становится понятнее
Рад что информация оказалась полезной)
Жаль, что в конце в коде так и не показал механику с refresh токенами.
Непонятно именно как рефрешь обновляет access.
куча объяснений в интернете, попробую описать кратенько. С клиента отправляется запрос с токеном в заголовках, на бекенде мы смотрим в него и проверяем токен через метод библиотеки. Если токен протух тут два пути - перехватывать на сервере или через клиент, то есть отбработать механизм отправки запроса на рефреш токена, который возьмет его уже из куков нашего клиента. Этот токен тоже нужно проверить на срок годности и валидность соответственно, (плюсом дополнительные проверки, если имеются в базе данных и поиск токена и юзера с ним в БД). Если все ок то отдаешь новую пару токенов и ставишь их в куки клиента. Если на каком-то из этапов провал в ошибку - то выход из сессии
Можно ли использовать рефреш токен как jwt? А в jwt написать под каким id хранится в базе токен и изменять его если не истёк exp. И Я так понимаю у вас в приложении можно иметь только одну сессию, пока не обновится рефреш.
Я не понял одного момента. Для реализации авторизации/аутентификации мы можем использовать токены или сесии. а здесь ты одно и другое слил вместе. так норм делать?
Спасибо за труд
есть подписчики которые не понимают назначения jwt и советуют куки:) напомню что назначение jwt для архитектуры распределённых серверов которым надо всеголишь раздать секрет-ключ-подписи и не заморачиваться с общим хранилищем сессий для всех микросервисов.
Хорошо объяснил! Такой вопрос, почему у твоего канала не отображается количество подписчиков?
Эх, жалко, что ты перестал снимать видосы по Go, а то контента не хватает. Всего хорошего тебе
Может переставить микрофон в другое место и под другим углом? шум мака 24/7))да и к тому же видно, что ты никогда не говоришь в микрофон. Как по мне хотябы просто повернуть в права так как ты сидишь и чуть вверх. И что-то со звуком в принципе будто-то глухо и объемно, на микро вроде должны быть режимы как брать звук направленно, либо повсюду и т.д
Ты так молодым и не объяснил зачем подписи. Сайты использующие сессии классические, при каждом запросе дергают из базы данных модель пользователя. jwt же позволяет от этого отказаться, ведь в 99% случаев дергают юзера просто чтобы узнать его id для дальнейших манипуляций)))
Зачем нужны jwt, если можно сразу в базе токены хранить?
Чтобы при каждом запросе не обращаться к базе данных за дополнительной информацией о пользователе, например за его ролью. Используя jwt мы можем хранить информацию о пользователе в токене, соответственно в middleware мы можем сразу достать эту информацию, не обращаясь при этом к БД. Если информацию подделают - токен станет недействительным. Благодаря refresh токенам мы обращаемся к БД лишь раз в 15 минут, вместо того, чтобы обращаться к ней при каждом запросе. Да, это немного сложнее, чем просто из БД нужную инфу доставать. Но мы ведь в go приходим за производительностью, правильно ?
@@Aaaa-jn4bm это может и работает хорошо в микросервисах, при общении между ними. Но для обычного сайта это только лишний геморрой. Например, если открыли 2 вкладки браузера, то уже нужно синхронизировать между ними эти токены
Да и часто бывает, что id пользователя мало, и приходится его все равно из базы тянуть.
@@sackeja , так для обычного сайта токены в http only куки должны сохранятся, и никакие вкладки тогда синхронизировать не нужно будет :)
И приведите пожалуйста пример такой информации, которую придётся тянуть из базы, вместо того чтобы поместить её в токен)) Никто так не делает, jwt именно для этого и создавалось - хранить информацию в токене, чтобы каждый раз не обращаться в бд
@@Aaaa-jn4bm ну да, с куками согласен
@@Aaaa-jn4bm ну пожалуй соглашусь, что в большинстве случаев можно все зашить в токен
вообще ошибочно про рефреш токен. он должен быть нормальным JWT со своим exp'ом. а тут вечный "рефреш токен" получается.
oauth 2.0 добавить title, сразу и не понял что это он.
Привет, Максим! Нужна ли тебе какая то помощь? Куда тебе можно написать?
Здравствуй! Добавляйся в Slack-комьюнити проекта Creatly - join.slack.com/t/creatlyworkspace/shared_invite/zt-10exogwme-IPDg1bFaH~RfAKYCY~~z8g
Там мы можем пообщаться, а в скором времени я скину список задач, которые можно делать
Эта популярная библиотека для работы с jwt нынче мертва. Автор её забросил, пара тройка критических проблем и с awesome-go ссылку на неё тоже убрали
так ты же переизобрел сессии... все это ради меты о юзере в токене? я бы с таким успехом заюзал редис. клал бы инфу о юзере в формате {сессия: мета_юзера} и все. а сами сессии в базе. в кеш закидывать на часов 12, чтоб базу не мучить лишний раз.
еще очень интересно почему выбор пал на нереляционную базу, потому как модель данных напротив - реляционная(если я правильно понял).
спасибо за видео и старания.
Не совсем. При получении токена я не обращаюсь ни к какому внешнему хранилищу (БД или Редис), а вся нужная информация хранится в токене.
Изначально я проектировал модель данных под реляционную БД, но решил взять Mongo.
1) С точки зрения инфраструктуры это дешевле на начале (На MongoDB Atlas можно развернуть монгу в облаке и использовать ее бесплатно до 512 мб, что мне сейчас очень подходит). Я решил что не хочу самостоятельно разворачивать БД и админить ее, проще немного доплатить за DBaaS и спокойно спать по ночам.
2) Поскольку мой проект - стартап, модель данных будет неизбежно изменятся и обновляться. Специфика монги позволяет легко вносить изменения и не морочить себе голову с миграциями в SQL.
3) Я последний раз работал с монго почти 3 года назад, и тот проект имел плохую архитектуру. Решил что хочу попробовать поработать с ней еще раз уже самостоятельно на своем проекте и познакомиться с ней лучше на практике)
Слушай а ты не знаешь как в своем IDE масштаб увеличить?)
С телефона смотреть вообще не возможно... Ну очень мелко.
Подумай об этом)
На кой черт так все слишком усложнять? при авторизации ты генерируешь некий уникальный строковый идентификатор и передаешь пользователю - теперь это твоя кука. По этой куке ты узнаешь в своей таблице авторизованных пользователей, кто есть кто. ВСЕ.
Чтобы при каждом запросе не обращаться к базе данных за дополнительной информацией о пользователе, например за его ролью. Используя jwt мы можем хранить информацию о пользователе в токене, соответственно в middleware мы можем сразу достать эту информацию, не обращаясь при этом к БД. Если информацию подделают - токен станет недействительным. Благодаря refresh токенам мы обращаемся к БД лишь раз в 15 минут, вместо того, чтобы обращаться к ней при каждом запросе. Да, это немного сложнее, чем просто из БД нужную инфу доставать. Но мы ведь в go приходим за производительностью, правильно ?