Как по запросу пользователя правильно отдавать данные для администратора и гостя?

Question

[Boris007]

Заходя на страницу localhost:3000/5
Мы на клиенте делаем запрос по апи на

router.get('/:id', async (req: Request, res: Response): Promise<void> => {
   const result = await User.readById(id)
})

Если я правильно понял, мы читаем токен доступа в котором сравниваем user_id с result.id
Если они совпадают, делаем дополнительные запросы на сообщения пользователя и т.п.
Т.е. на все сервисы, которые доступны для администратора данной страницы

На клиенте в свою очередь нам нужно иметь два шаблона компонента главной страницы и при посещение любой из страниц, на клиенте сравнивать из токена так же совпадение token.user_id с id из url и рендерить шаблон с кнопками, которые для владельца этой страницы?

В токене же безопасно хранить user_id для этих манипуляций?

Comments

[szQocks]

по ролям отдаёшь просто разный контент, или по ролям какие-то энпоинты на сервере доступны для запросов, а какие-то нет

например есть ендпоинт на сервер localhost:5000/api/get-user-info - когда ты сюда отправляешь запрос, на сервере проверяешь токен доступа, если он валидный, ищешь юзера в бд по айдишнику и если юзер есть - проверяешь роль юзера, если это админ - отдаёшь одни данные, если это простой юзер - отдаёшь другие

Answer 1

[Максим]

Используйте JWT токен, в котором будет ID и роли. По пори проверяйте есть ли доступ администратора. В каждом запросе делать проверку не нужно. Это можно закрыть глобально по роли.

Comments

[Boris007]

Немного не понял
У нас есть access_token
В нем мы храним id пользователя, верно?
И при каждом заходе на страницу, мы должны его обновлять для смены в нем user_role?

[Максим]

Boris007, не просто access_token, а именно формата JWT. При входе он должен создаваться вместе с RefreshToken. AccessToken имеет срок действия, обычно до 15 минут. Как заканчивается - получаете новый с помощью RefreshToken. И у вас новый AccessToken. Таким образом достигается безопасность.

JWT токен позволяет без запроса на сервер аутентификации получить полезную нагрузку, которая включена в этом токене. Чаще всего в неё включаются данные User и его роли. Декодировав этот токен вы можете использовать эти данные.

Лучше почитайте о данном токене.

[Boris007]

Максим, у меня есть access token, я в нем храню id пользователя, срок действия и роль, как я понял
Если с id (который равен его id в таблице users) и сроком действия (через которые токен станет не действителен) все понятно, как именно хранить в нем роль?

У человека есть своя страница на которую можно зайти по
site.ru/boris007
Он авторизировался и получил ключи

И вот решил он зайти на страницу
site.ru/maxim007

Как понять серверу и клиенту, что на сервере нам надо отдать данные, которые разрешены только для гостя или для администратора
А на клиенте понять, что надо отобразить ему шаблон гостя без кнопок действия или со всеми кнопками владельца страницы, а может и вообще без кнопок, потому что человек не авторизировался на сайте и ему доступен только просмотр без возможности добавить в друзья

[Максим]

Boris007, если говорить о сервере, то ему с запросом нужно передавать в header этот токен. В принципе как и обычно с другим токеном. Данный токен сервер не сохраняет себе в куки или ещё куда-либо. Он просто проверяет его и если он валиден по структуре, подписи, и не просрочен, то авторизует пользователя в рамках одного запроса. Далее сервер проверяет есть ли у авторизованного пользователя роль admin. Если нет, то ошибка 403.

Клиент же должен обрабатывать эту ошибку и показывать пользователю. Так же клиент может по условию показывать кнопку.

Как понять серверу и клиенту, что на сервере нам надо отдать данные, которые разрешены только для гостя или для администратора

Если у вас это публичные профили страницу можно отобразить всегда. А вот какие данные показать зависит от авторизованного пользователя. Обычно управление профилем пользователя и публичный профиль разные страницы. У вас вообще не должно быть возможности заменить url и отобразить чужой профиль. В данном случае с сервера вам должен прилетать только свой профиль или 401. Вы при этом передаете только токен.

Кнопку добавить в друзья вы отображаете в зависимости от того есть ли у вас JWT токен в куках, далее он валиден и не просрочен. Если всё это success, то у вас пользователь авторизован. Вы можете добавить к себе в друзья. При этом надо не забыть проверку на то что это это ещё профиль не ваш.

[Boris007]

Максим, я немножко воробушек

Далее сервер проверяет есть ли у авторизованного пользователя роль admin

Каким образом?
Сравнивает user_idв токене и id запрашиваемого пользователя?

Если нет, то ошибка 403.
А если он зашел просмотреть чужую страницу, как гость и написать ему (кнопка написать находится на странице пользователей)

[Максим]

Boris007,

Каким образом?

Можно сравнивать ID, но в вашем случае запрос будет без передачи ID: example.com/profile. Внутри этого запроса из токена вы получаете ID авторизованного пользователя. Далее с этим ID получаете профиль пользователя из БД. То есть у вас не будет ссылки вида example.com/maxim007 в которой пользователь редактирует свой профиль. По ссылке example.com/maxim007 вы просто отображаете профиль, а по ссылке example.com/profile редактируете свой профиль. При этом вы можете сделать кнопку "Редактировать", которая ведёт на профиль редактирования

const identity = getIdentity()

if(identity !== null && profile.id === identity.id) {
  return <a href="/profile/edit">Редактировать профиль</a>
}

А если он зашел просмотреть чужую страницу, как гость и написать ему (кнопка написать находится на странице пользователей)

Обычно написать гости не имеют возможности. А чтобы не было 403 страницы при отображении - разнесите на разные. Но если у вас пользователь гость, то вы скрываете кнопку, так как на клиенте у вас не будет токена и user будет равным null.

const identity = getIdentity()

if(identity !== null && profile.id !== identity.id) {
  return <a href="/message...">Написать сообщение</a>
}