Как проверять разрешения пользователей в nuxtjs приложении?

Question

[not_cool]

Нужно закрывать некоторые роуты и не показывать некоторые части компонентов в зависимости от разрешений пользователей. До этого читал про RBAC и принцип работы этой системы вроде подходит.
Первая мысль была получать после логина вместе с объектом юзера все его разрешения, сохранять во vuex, и потом через геттер проверять наличие нужного разрешения внутри компонентов и при переходе между роутами, или во время рендеринга на сервере проверять наличие токена и если он есть получать по нему юзера и сохранять в стор.
Но зачем тогда используют библиотеки типа vue-kindergarten или casl?
И можно ли как нибудь учитывать иерархию операций, например если есть операция "updatePost" и задача "updateOwnPost" у которой потомок это "updatePost", и два юзера, у одного разрешение "updatePost", у другого "updateOwnPost". Можно ли сделать чтобы при проверке в шаблоне разрешения на "updatePost" у первого проверялась только она, а у второго проверка поднималась по иерархии до "updateOwnPost"? Или это должны быть два разных разрешения и в шаблоне проверять наличие обеих?
Или для этого что-то другое используется обычно?

Comments

[crdrads]

Примерно так же как и в Vuejs приложении!

Answer 1

[Антон Антон]

Само приложение выполняется в недоверенной среде, по этому все (значимые) действия пользователя должны проверяться в доверенной среде (на сервере). Соответственно, должно быть API, по которому каждое действие проверяется. Сами ссылки можно, наверное, подгружать с сервера при старте, но все данные при переходе по ним - обязательно с проверкой на сервере каждый раз.

Comments

[not_cool]

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

[Антон Антон]

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

Answer 2

[Николай]

Ну раз используешь nuxt, то почему бы не использовать официальный модуль auth? В этом модуле, когда получаешь объект пользователя можно передать scope. А потом обращаться так: this.$auth.hasScope('admin')

Если хочешь сам, то посмотри исходники. Но смысл там такой, получаешь токен, сохраняешь токен, по токену получаешь объект пользователя и хранишь его в vuex.

Логику проверки scope ты можешь сам реализовать какую захочешь, если напишешь свой геттер для vuex, который будет работать с сохраненным объектом пользователя

Comments

[not_cool]

Так смысл в том чтобы не проверять роль, а проверять конкретную операцию, потому что ролей может быть например 30, и операция доступна в 10 из них, тогда придется делать условие на проверку этих десяти ролей. Плюс может быть для такая операция которая для одной роли выполняется без условий, а для другой только с условием совпадения каких то параметров объекта и юзера. Или через официальный auth это можно как то сделать?
Пока нашёл библиотеку CASL, вроде делает то что нужно, но смущает что права для ролей хранятся на фронте и при добавлении роли придется добавлять и на бекенде и на фроненде

[Николай]

not_cool, роли и правила в любом случае придется хранить на бэкенде и перепроверять права при запросах, т.к. фронтенду ну никак нельзя доверять. Чтобы не писать два раза, можно получать права с бэкенда. Кстати тут есть пример. Auth не занимается подобным, но нет никаких сложностей использовтаь CASL поверх auth.

Как устроено приложение? SPA, SSR? Что на бэкенде?

[not_cool]

Николай, на фронте vue + nuxtjs, бекенд на отдельном проекте с node и express, связываются только через api.
Почитал доки casl и оказалось что правила действительно можно с бекенда получать, потому что они просто объект.
Получается примерно так должно быть: при логине сервер с апи возвращает токен и объект пользователя с правами, токен устанавливается в куку или в хедер, потом при действиях проверяются правила на фронте, если ок, то запрос отправляется на бекенд, там сервер по токену получает юзера и выполняет действие проверяя его права? Тогда во время рендеринга на сервере нужно проверять наличие токена и если он есть то получать объект юзера с правами с помощью этого токена вместо логина и пароля, и потом выводить страницу, сделанную под этого юзера?