Pull to refresh

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 дней назад и при каждом использовании время сбрасывается. Но использоваться он может только для доступа для чтения, чтобы получить доступ на запись, мы можем спросить у юзера его пароль (и при этом сгенерировать токен более высокого уровня доступа, время жизни которого — несколько минут), а если он еще при этом хочет и сменить пароль, или почту, то вообще использовать двухфакторную аутентификацию.

Ну и если ваше АПИ будет заставлять каждый раз присылать логин/пароль, то и приложение, работающее с этим АПИ вынужденно хранить в памяти логин/пароль юзера, после того, как он зашел в него, что может быть реализованно не слишком безопастно. Обычно все-таки сервис аутентификации после удачной аутентификации отдает короткоживущий токен, который и используется на протяжении работы приложения.
Имхо для пользователей нужно использовать rfc5054

для s2s hawk
Sign up to leave a comment.