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

Question

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

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

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

Answer 1

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

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

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

• пользователя (персональные данные)
• UserGroup (данные роли)
• Right (что может быть разрешено или запрещено, смотрите на «команде»)
• UserGroup_right (отображение)
• Session (время Логина и другие данные, связанные с текущей работой)
• SessionRights (должно быть заполнено при входе пользователя)

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

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

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

Answer 2

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

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

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