Как реализовать регистрацию в RESTful приложении?

Question

[Keksonov]

Нужно реализовать регистрацию. Также на frontend отслеживать, залогинен ли пользователь и его группу (администратор, пользователь)

Answer 1

[Vladimir Rozhkov]

Регистрация:
POST /api/signup, в тело запроса передается емейл/логин и пароль + нужные вам пользовательские данные. Сторите это дело в базу, пароль конечно же хешируете bcryptом.

Логин:
POST /api/login, в тело запроса передается логин и пароль. Достаете пользователя из базы, хешируете пароль, сравниваете с сохраненным. Если не ок – 401 до свидания, если ок:

Генерируете JWT токен, в токен записываете логин и роли, ставите дату протухания. Токен обязательно подписывается HS256 или сильнее.
Токен ставите в респонс в хидер X-Auth-Token или возвращаете в респонсе или еще как угодно. Кроме этого возвращаете на фронт его роли чтобы фронт знал что надо рисовать.

Фронтенд сохраняет токен в печенье или локалсторедж и передает с каждым запросом.

На каждый запрос вы
1. Смотрите есть ли токен в хидере. Если нет – 403.
2. Валидируете его (обязательно ставите сами алгоритм подписи, а не берете из самого токена), и смотрите не протух ли. Если невалидный или протух – 403.
3. Достаете оттуда емейл и роли. Смотрите, доступен ли ваш эндпоинт этим ролям. Если нет – 403.
4. ...
5. PROFIT!

Время от времени токен надо рефрешить. Еще можно в токен напимер записывать ІР пользователя и кучу другой полезной информации.

Ключевые слова для гугления – JWT auth, даже не знаю что еще добавить.

Comments

[Keksonov]

Логаут сделать удалением токена?

[Vladimir Rozhkov]

Keksonov
Логаут делается на фронте – чистится печенька или локалсторедж.
Это если наши токены нигде не хранятся. Если хотите – можете хранить токены в редисе и их оттуда удалять, но тогда у нас уже будет состояние, надо будет ходить в редис проверять есть ли там такой токен и так далее, а это не круто.

[Keksonov]

Vladimir Rozhkov: После успешной
авторизации мне на фронтенд отправлять данные о юзере, для того, чтобы правильно отрисовать ui?

[Vladimir Rozhkov]

Keksonov
Да, на фронт отправляешь роли и все что нужно. Главное дальше чтобы у тебя АРІ проверял что у пользователя есть права на то, что он делает, а не просто сделать такое ограничение на фронте.

[Keksonov]

Vladimir Rozhkov: Как реализовать эту проверку?

[Vladimir Rozhkov]

google node js check user role middleware

Не знаю на чем вы пишете, в зависимости от фреймворка.

[Илья Румянцев]

Не забываем о том что если токен украдут и он бессрочный то вы никак не сможете повлиять на него. Как написал Keksonov нужно его перевыпускать или использовать 2 токена 1й- access_token, 2й- refresh_token
Вот статейка для вхождения Зачем нужны 2 токена?

Answer 2

[Иван GiBSON]

Передавать статус пользователя в изначальном html (инлайн js), либо запрашивать с фронтенда при инициализации приложения. А регистрация и авторизация ничем не отличается, ну разве что ходит ajax'ом к апи. Просто по факту ее свершения возвращается json например с необходимыми данными

Comments

[Keksonov]

После авторизиции отдам токен. Что с этим токеном делать на фронтенде? Что я ещё должен отдавать?

[Vladimir Rozhkov]

Токен на фронтенде нужно сохранить в печенье или локалсторедж и передавать его на каждом запросе.
Вы на сервере парсите токен и верифицируете его.

Вообще если вы такие вопросы задаете, то знаний у вас явно недостаточно, почитайте туториалы типа https://scotch.io/tutorials/building-and-securing-...

[Keksonov]

Vladimir Rozhkov: Читал, хочется узнать разные точки зрения на этот вопрос.

[Иван GiBSON]

Keksonov: Все зависит от того как дальше работа организована, если у вас апи дергаться будет на том же домене и/или нужен серверный рендеринг тогда можно поставить куки, а про сам токен вообщем то забыть (по умолчанию куки на тотже домен и так уходят (через fetch нет)).
Если апи на другом домене ну тогда токен сохраняем в ls или cookie, но опять таки если нужен серверный рендер тогда куки лучше.