Разработка механизма разрешений пользователей

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

Библиотекарь ограничил доступ к данным по сравнению с Администратором. Например, библиотекарь не может просматривать клиентов из другой библиотеки или другого отдела в той же библиотеке. Так что мне нужно разработать логику разрешений.

Я прошу совета, как лучше всего разрабатывать механизмы разрешений? Что делать на уровне базы данных? Что делать на уровне бизнес-логики?


architecture user-permissions permissions design-patterns software-design
person nickolay    schedule 01.09.2015    source источник
comment
Непонятно, что вы ищете. Разве пользователь не входит в вашу систему. Как только он войдет в систему, вы узнаете тип пользователя и просто разрешите / запретите или покажете операции скрытия в соответствии с ролью пользователя.   -  person Guanxi    schedule 02.09.2015

Ответы (2)


arrow_upward
1
arrow_downward

Это зависит от чувствительности ваших данных. Вы можете установить права доступа на уровне базы данных и использовать разные входы в базу данных. Но это кажется слишком строгим для вашего случая ... Я бы решил это с помощью обычного входа в базу данных и управления правами на основе приложений.

Шаблон команды (https://en.wikipedia.org/wiki/Command_pattern) очень полезен. ... Вы можете назначить по одному праву для каждой команды.

Один из распространенных способов (а их гораздо больше) может выглядеть так ... Вам понадобятся следующие таблицы:

  • Пользователь (личные данные)
  • UserGroup (данные о ролях)
  • Правильно (что можно разрешить или запретить, см. "Шаблон команды")
  • UserGroup_right (сопоставление)
  • Сессия (время входа в систему и другие данные, связанные с текущей работой)
  • SessionRights (заполняется при входе пользователя)

Пользователь является членом группы пользователей (= роль). Вы привязываете права к этой группе. Когда пользователь входит в систему (в ваше приложение), система знает членство (а) пользователя в группе и собирает связанные права. Любой элемент управления / меню в вашем приложении реагирует автоматически (становится невидимым или отключенным).

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

Надеюсь это поможет!

person Shnugo    schedule 05.09.2015

arrow_upward
0
arrow_downward

Вы должны отправлять разные приложения разным типам пользователей.

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

Если вы не ожидаете, что одна платформа будет часто менять контекст разрешений пользователей, то я думаю, что первое решение будет проще в исполнении и будет более надежным.

person Wylie Kulik    schedule 05.09.2015