Советы по разработке приложения с различными уровнями разрешений

Question

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

Любой совет?

Как бы вы (вы) использовали такую ​​функциональность в вашем приложении?

Answer 1

Сначала вам нужно выяснить, какие функции вы хотите охватить своей системой разрешений, и в каких деталях:

• Доступ к таблицам (список, CRUD)

• Функция / модули

• Доступ на уровне записи (= ACL)

• Положительная (предоставление) или Отрицательная (отзыв) семантика

• Что разрешено делать роли «администратор»

Если вы хотите ограничить доступ к таблицам, вы можете легко настроить дополнительную таблицу, содержащую все имена таблиц, и предоставить select-list / select-record / insert / update / delete доступ к ролям / группам, как показано на рисунке. СП.

Если вы хотите предоставить доступ к функциям или модулям, имейте таблицу модулей и предоставьте выполнение ролям / группам.

Обе функции эквивалентны грантам в SQL.

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

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

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

Answer 2

Может быть, это немного тупик, чтобы следовать концепции «уровней». Это может удовлетворить ваше текущее приложение, однако модель данных, которая состоит из сопоставления ролей и привилегий, является более общей и подходит для большинства целей.

Назначение ролей пользователям. Пользователь может иметь более одной роли, и его роль (-и) определяют права, которые они имеют. Концепция похожа на группы, однако «роль» обычно легко сопоставляется непосредственно с бизнес-логикой (например, роли «администратор», «пользователь», «клерк», «менеджер по работе с клиентами», «региональный менеджер» и т. Д.). Привилегии также отображаются непосредственно на функции и объекты данных. Вы также можете отобразить реализации, которые используют базовый контроль доступа к платформе (например, привилегии Java).

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

В своем проекте вы можете визуализировать / документировать систему контроля доступа в виде матрицы (роли для привилегий).

Answer 3

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

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

Answer 4

Это частичная диаграмма ER для модуля идентификации в Turbogears, Python. Он реализует то, что вы ожидаете. Пользователи связаны с группами, а группы имеют соответствующие разрешения.

Возможны два способа ограничения доступности функций:

1. (я предпочитаю) В ваших контроллерах проверьте группу, к которой принадлежит пользователь, и отредактируйте ваш ответ на просмотр в соответствии с этим. Таким образом, View - это всего лишь средство визуализации, а не бизнес-логика.
2. Представление получает сведения о пользователе, такие как группы и разрешения, и решает, что отображать, а что нет (MVC нарушен).

Узнайте больше о MVC (и Turbogears).

альтернативный текст http://jaivikram.verma.googlepages.com/temp.jpeg