Как я могу улучшить функции промежуточного программного обеспечения авторизации на основе ролей API - PullRequest
0 голосов
/ 29 мая 2020

У меня возникли проблемы с тем, как улучшить функции промежуточного программного обеспечения авторизации на основе ролей API. Я использую Sequelize, Node.js, Express и Postgres.

Я настраиваю свою структуру API в формате:

Группы => A - SuperAdmin B - Admin, B1, B2, B3 C - C1, C2, C3 D - D1, D2, D3, D4

Роли => 1 - суперадмин 2 - админ 3 - b1 4 - b2 5 - c1 6 - c2 7 - d1 8 - d2

Пользователь принадлежит к одной из групп и имеет одну роль.

ЧТО Я ХОЧУ ДОСТИГАТЬ

Я пытаюсь реализовать ситуацию, когда пользователи могут редактировать только контент, который они отправили, если у них нет роли администратора. Кроме того, они могут получить доступ только к контенту для уровня своей группы, для которого они авторизованы.

ЧТО Я ДЕЛАТЬ В ТЕЧЕНИЕ

  1. У меня есть checkPrivilege функция, которая проверяет, принадлежит ли пользователь к группе и имеет ли назначенную ему роль, прежде чем он сможет получить доступ к контенту. Это работает нормально.

  2. У меня есть функция checkPrivilegeForEdits, которая проверяет, принадлежит ли пользователь к группе и есть ли у него роль, прежде чем он получит разрешение на редактирование содержимого.

  3. У меня есть функция fooEditor, которая проверяет, есть ли у пользователя права редактировать этот конкретный файл foo. Проблема в том, что для этого у foo должно быть много пользователей. Это означает, что в пользовательской таблице будет поле fooId. Следование этому методу означает, что у меня будет сценарий, в котором у меня есть barId в пользовательской таблице, bazId в пользовательской таблице. или, поскольку многие таблицы потребуют редактирования, мне придется объявить отношение «один ко многим».

  4. У меня есть функция verifyModels.checkFooExist, которая проверяет, существует ли foo. Я добавил это в метод обновления пользователя.

ЗАДАЧА

При текущей настройке только пользователи, которым назначена работа над таблицей Foo, могут получить к ней доступ. При регистрации им нужно будет ввести значение в поле FooId в пользовательской таблице. Я не думаю, что имеет смысл иметь много tableId в таблице user. Что у нас есть до 50 таблиц, которые необходимо редактировать.

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

et updatedUser = await User.update({
// username: req.body.username,
email: req.body.email,
displayName: req.body.displayName,
fooId: req.body.fooId,
barId: req.body.barId,
bazId: req.body.bazId,
table1Id: req.body.table1Id
},

Итак, в настоящее время мой маршрут обновления foo выглядит так:

router.patch('/:id', authVerify.verifyToken, (req, res, next) => verifyGroups.checkPrivilegeForEdits(req, res, next, db.GROUP.mng, null), verifyEditors.fooEditor, fooCtrl.updateFooRecord);

, а мой маршрут обновления пользователя выглядит так:

router.patch('/update/:id', [authVerify.verifyToken, verifySignUp.checkRolesExisted, verifyModels.checkFooExist], userCtrl.updateUser);
  1. Как я могу улучшить это, чтобы избежать необходимости объявлять какие-либо отношения между таблицей пользователей и Foo или другими таблицами?

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

...