Angular 2+ Role Permissions

Question

В настоящее время я делаю небольшой проект с использованием Angular 6, чтобы попрактиковаться в взаимодействии клиент-сервер. Это простой сайт в стиле блога, где пользователи могут просматривать посты других пользователей и создавать свои собственные.До сих пор я занимался аутентификацией JWT и защитой маршрутов, чтобы предотвратить просмотр защищенных ресурсов кем-то, кто не вошел в систему.

Структура проекта в настоящее время такова, что у каждого пользователя есть профиль пользователя, отображаемый компонентом ProfilePage,В моем маршрутизаторе я перехожу к правильной странице пользователя со структурой /user/:username, где :username - это конкретная страница пользователя, для которой сервер будет отправлять обратно соответствующие данные.Проблема, которую я пытаюсь решить, состоит в том, как сделать так, чтобы пользователь, вошедший в свою учетную запись, мог добавлять и удалять сообщения только на своей странице профиля, а не чужие.

Я ознакомился с разрешениями и ролями пользователей, однако, если у обоих пользователей есть роль «ПОЛЬЗОВАТЕЛЬ», как я могу различить, когда пользователь смотрит на свою страницу или нет?

Некоторые идеи, которые у меня были:

1. Динамически проверять разрешения на странице, когда пользователь переходит на нее, поэтому я отправляю запрос на сервер (с JWTна предъявителя) и отправляет обратно статус роли пользователя / редактора для страницы, а затем, когда пользователь публикует что-либо, сервер снова проверяет, что пользователю разрешено публиковать, прежде чем вносить изменения в серверную часть.

2. Еще одна идея, которая у меня была, заключалась в создании отдельного компонента MyProfile, который действует, выглядит и выглядит как профиль пользователя, за исключением кнопок редактирования.Проблема, с которой я могу столкнуться при этом, заключается в том, что позже у меня возникнут проблемы, когда я реализую роль ADMIN, которая может удалять сообщения любого пользователя (за исключением этики в образовательных целях этого проекта).

3. Аналогично первой идее, но когда пользователь входит в систему, запишите его имя пользователя и просто проверьте это разрешение на стороне клиента, а затем на стороне сервера, когда они фактически создают / удаляют сообщение, чтобы убедиться, что ему действительно разрешено это делать.,

Кажется ли какой-либо из этих вариантов реальным способом продвижения вперед?Если я могу сделать это все еще с Гвардией, как так?

Answer 1

Я бы поставил собственную страницу профиля пользователя по своему маршруту, а не по тому же маршруту, что и у других.Таким образом, вы можете обеспечить всю безопасность (на стороне сервера) на личной странице личного профиля, в то время как страницы профиля других пользователей были бы общедоступной страницей, лишенной возможности редактировать, удалять, добавлять и т. Д.

Answer 2

Я пойду к вашему решению 3.

На самом деле вам даже не нужно хранить имя пользователя вашего пользователя при входе в систему.Поскольку вы принимаете авторизацию JWT в своем приложении, вы должны вместо этого хранить токен JWT (вам даже не нужно сохранять его вручную, если он установлен в ваших куки при входе в систему).

Ваш токен JWT должен включать оченьосновная информация (возможно, имя пользователя или UUID и другие, которые вы считаете подходящими) о вашем пользователе, а также информация о токене.Вы должны использовать этот токен JWT для получения информации о пользователе из вашего бэкэнда, когда ваш пользователь обращается к странице профиля.(т.е. прикрепите этот токен-носитель JWT в заголовок авторизации или включите его в куки-файлы. Ваш бэкэнд должен прочитать этот токен JWT и получить уникальный идентификатор (имя пользователя / uuid в соответствии с предложением) для получения информации о пользователе)

Когда пользователь собирается обновить информацию о пользователе, вам следует снова присоединить токен-носитель JWT, а бэкэнд должен при необходимости отменять запросы.

Я бы также рекомендовал просто включить маршрут /user,или что-то вроде /myprofile маршрута для обычных пользователей.Маршрут /user/:username должен быть открыт только для тех, кто имеет право просматривать чужой профиль, говорит администратор.