Comments 3
Ненавижу писать авторизацию. И вроде не в первый раз. И фреймворков куча и всяких библиотек. Каждый раз боль. Вот как раз на таком и выгорают.
ЗЫ: У меня сайт для комфортного чтения хабра и виси. Только что закончил авторизацию. Ну и открываю сайт, чекнуть что разломалось после выкатки - а тут эта статья. Не претендую на истину в последней инстанции, но всегда стараюсь делать по последним инструкциям ВЦСПС. Куки шифрую, нагрузку на бд минимизирую, код стараюсь держать чистым. Вобщем на стандартной библиотеке авторизация/аутентификация у меня получилась такой: https://github.com/recoilme/dogenews
А сам пайплайн следующий.
Новый юзер заходит на сайт:
создаем новую запись в бд
юзера сериализуем в json
шифруем в jwt
сохраняем в куку
Старый юзер заходит на сайт:
читаем куку ( в ней должно быть все что нужно без похода в бд)
валидируем
десериализуем
Обновить инфу:
обновляем в куке и в бд
Подводные камни:
допустим есть id и telegram_id. Хотим чтобы если есть telegram_id - чекался на уникальность. int64 который может принимать значение nil отцы гоу советуют делать так *int64. Не забывайте чекать на nil если не задан
Кука если задается должна задаваться первой в ответе (это хидер https://datatracker.ietf.org/doc/html/rfc6265#section-5.4)
Что делать в случае браузеров не поддерживающих куки я в общем случае не знаю (стараюсь не думать об этом)
Ну и типичные грабли на которые наступаю каждый раз - рассинхрон БД и Куки. Вроде тяжело не обосраться в этом месте, но каждый раз удается
Предполагается, что REST — это архитектура ПО, при использовании которой сведения о состоянии запросов не хранятся.
На самом деле это определяется исключительно логикой и нуждами вашего приложения. Какое-нибудь приложение вроде банковского, когда пользователь может несколько дней не заходить, потом зайти и сделать несколько операций в течении минут, без использования понятия сессий будет более костыльным и менее логичным. Любые операции, где пользователь должен последовательно выполнить несколько шагов: (энроллмент, разбитый на несколько шагов и переход к следующему шагу только после завершения предыдущего, интернет-магазин, где сначла набираем корзину, потом вводим адрес, оплачиваем, все это разные шаги), мы здесь вынужденны хранить состояние пользователя.
По поводу токенов, токены очень полезны даже тогда, когда вроде-бы нет необходимости в сессиях, ибо разные токены могут иметь разный уровень доверия. К примеру, чтобы пользователю зайти в приложение, достаточно токена сгенерированного несколько дней назад, при условии, что пользователь последний раз использовал его не познее, чем N дней назад и при каждом использовании время сбрасывается. Но использоваться он может только для доступа для чтения, чтобы получить доступ на запись, мы можем спросить у юзера его пароль (и при этом сгенерировать токен более высокого уровня доступа, время жизни которого — несколько минут), а если он еще при этом хочет и сменить пароль, или почту, то вообще использовать двухфакторную аутентификацию.
Ну и если ваше АПИ будет заставлять каждый раз присылать логин/пароль, то и приложение, работающее с этим АПИ вынужденно хранить в памяти логин/пароль юзера, после того, как он зашел в него, что может быть реализованно не слишком безопастно. Обычно все-таки сервис аутентификации после удачной аутентификации отдает короткоживущий токен, который и используется на протяжении работы приложения.
для s2s hawk
Разработка REST-серверов на Go. Часть 6: аутентификация