Отличное объяснение, как обычно 👍 для полной картины - было бы хорошо ещё пример, как это всё увязать с фронтом (почти всегда у новичков - это следующий запрос в Гугл) 😅
Можно ли использовать рефреш токен как jwt? А в jwt написать под каким id хранится в базе токен и изменять его если не истёк exp. И Я так понимаю у вас в приложении можно иметь только одну сессию, пока не обновится рефреш.
Я не понял одного момента. Для реализации авторизации/аутентификации мы можем использовать токены или сесии. а здесь ты одно и другое слил вместе. так норм делать?
куча объяснений в интернете, попробую описать кратенько. С клиента отправляется запрос с токеном в заголовках, на бекенде мы смотрим в него и проверяем токен через метод библиотеки. Если токен протух тут два пути - перехватывать на сервере или через клиент, то есть отбработать механизм отправки запроса на рефреш токена, который возьмет его уже из куков нашего клиента. Этот токен тоже нужно проверить на срок годности и валидность соответственно, (плюсом дополнительные проверки, если имеются в базе данных и поиск токена и юзера с ним в БД). Если все ок то отдаешь новую пару токенов и ставишь их в куки клиента. Если на каком-то из этапов провал в ошибку - то выход из сессии
Чтобы при каждом запросе не обращаться к базе данных за дополнительной информацией о пользователе, например за его ролью. Используя 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 Там мы можем пообщаться, а в скором времени я скину список задач, которые можно делать
Может переставить микрофон в другое место и под другим углом? шум мака 24/7))да и к тому же видно, что ты никогда не говоришь в микрофон. Как по мне хотябы просто повернуть в права так как ты сидишь и чуть вверх. И что-то со звуком в принципе будто-то глухо и объемно, на микро вроде должны быть режимы как брать звук направленно, либо повсюду и т.д
есть подписчики которые не понимают назначения jwt и советуют куки:) напомню что назначение jwt для архитектуры распределённых серверов которым надо всеголишь раздать секрет-ключ-подписи и не заморачиваться с общим хранилищем сессий для всех микросервисов.
так ты же переизобрел сессии... все это ради меты о юзере в токене? я бы с таким успехом заюзал редис. клал бы инфу о юзере в формате {сессия: мета_юзера} и все. а сами сессии в базе. в кеш закидывать на часов 12, чтоб базу не мучить лишний раз. еще очень интересно почему выбор пал на нереляционную базу, потому как модель данных напротив - реляционная(если я правильно понял). спасибо за видео и старания.
Не совсем. При получении токена я не обращаюсь ни к какому внешнему хранилищу (БД или Редис), а вся нужная информация хранится в токене. Изначально я проектировал модель данных под реляционную БД, но решил взять Mongo. 1) С точки зрения инфраструктуры это дешевле на начале (На MongoDB Atlas можно развернуть монгу в облаке и использовать ее бесплатно до 512 мб, что мне сейчас очень подходит). Я решил что не хочу самостоятельно разворачивать БД и админить ее, проще немного доплатить за DBaaS и спокойно спать по ночам. 2) Поскольку мой проект - стартап, модель данных будет неизбежно изменятся и обновляться. Специфика монги позволяет легко вносить изменения и не морочить себе голову с миграциями в SQL. 3) Я последний раз работал с монго почти 3 года назад, и тот проект имел плохую архитектуру. Решил что хочу попробовать поработать с ней еще раз уже самостоятельно на своем проекте и познакомиться с ней лучше на практике)
Ты так молодым и не объяснил зачем подписи. Сайты использующие сессии классические, при каждом запросе дергают из базы данных модель пользователя. jwt же позволяет от этого отказаться, ведь в 99% случаев дергают юзера просто чтобы узнать его id для дальнейших манипуляций)))
На кой черт так все слишком усложнять? при авторизации ты генерируешь некий уникальный строковый идентификатор и передаешь пользователю - теперь это твоя кука. По этой куке ты узнаешь в своей таблице авторизованных пользователей, кто есть кто. ВСЕ.
Чтобы при каждом запросе не обращаться к базе данных за дополнительной информацией о пользователе, например за его ролью. Используя jwt мы можем хранить информацию о пользователе в токене, соответственно в middleware мы можем сразу достать эту информацию, не обращаясь при этом к БД. Если информацию подделают - токен станет недействительным. Благодаря refresh токенам мы обращаемся к БД лишь раз в 15 минут, вместо того, чтобы обращаться к ней при каждом запросе. Да, это немного сложнее, чем просто из БД нужную инфу доставать. Но мы ведь в go приходим за производительностью, правильно ?
