Лучшие практики для контроля разрешений?

Question

Привет всем, мне нужен совет по этому вопросу ...

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

У меня такой вопрос: существуют ли более общие / лучшие способы обработки разрешений, применяемых к элементу формы на странице, чем написание метода безопасности / проверки на странице для включения / отключения / скрытия / отображения надлежащих элементов управления в зависимости от разрешенных разрешений?

У кого-нибудь есть опыт работы с этим по-разному?

Edit:

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

Ура! * * 1013

Answer 1

Прошу прощения за то, что я немного не по теме, но учитесь на моей ошибке:

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

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

Answer 2

Вы можете проверить, как django обрабатывает формы и проверяет их. Формы обрабатываются как модели, у них есть собственный класс, поэтому их список полей, правила проверки и логика отображения больше не разбросаны по всему представлению, контроллеру и помощнику. С такой структурой становится совершенно ясно, где находится скрытая / только для чтения / редактируемая логика.

Похоже, что такая функция еще не реализована в рельсах. Это не только экономит время, но и сохраняет ваш код чистым и структурированным. Вы можете начать с создания базового класса для форм, где валидация отделена от контроллера.

Answer 3

Я думаю, что есть больше возможностей, чем вы думаете.

• Скрыто / Видимо - поле видимое или нет
• Пусто / Система / Без изменений - система изначально устанавливает значение пустым или какое-либо значение, предоставленное бизнес-правилом, или оно остается как есть
• ReadOnly / Editable - может ли пользователь изменить значение
• Обязательный / LeaveBlank / Необязательный - это поле, обязательное для заполнения, не должно быть пустым, или его можно оставить пустым, если оно было пустым с самого начала, или оно является необязательным и может быть пустым в любом случае

Также вам необходимо учитывать множество факторов, которые влияют на принятие решения

• Роль - обычно пользователь имеет 1 или более ролей, и эти роли могут разрешать или запрещать различные возможности.
• Состояние - состояние рассматриваемого объекта часто определяет, какие поля редактируются независимо от роли
• Объект - часто значения самого объекта определяют то, что разрешено, когда, помимо просто его статуса
• Задача - вы можете разбить редактирование на большее, чем просто читать и редактировать
• Раздел - я часто хочу управлять настройками для всего раздела объекта или экрана, и все элементы управления наследуют эти настройки, но при необходимости могут переопределять их индивидуально

Осуществление? Во-первых, убедитесь, что у вас есть четкое представление о том, как обрабатывается жизненный цикл страницы. Мой обычно идет примерно так.

• Получите объект, который они редактируют, обычно из состояния сеанса, иногда, если они выполняют «новую» операцию, вам может понадобиться создать структуру данных заглушки для работы с ними.
• Если страница загружается впервые, включите варианты в раскрывающиеся списки, обычно это общий процесс, выполняемый только один раз.
• Если это постбэк, обновите редактируемый объект, считав значения из элементов управления
• Обработка событий, таких как нажатия кнопок
• Выполните все ваши бизнес-изменения, они должны изменить структуру данных, которые они редактируют.
• Обновление видимости и возможности редактирования элементов управления на основе всех имеющихся у вас данных.
• Заполните элементы управления данными от редактируемого объекта, включая сообщения проверки или сообщения об ошибках

Answer 4

Для правильной работы я обнаружил, что уровни доступа должны быть в этом возрастающем порядке: НЕТ, ПРОСМОТР, ТРЕБУЕТСЯ, РЕДАКТИРОВАТЬ.

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

Перечисление будет выглядеть так:

/** NO permissions.
 *     Presentation: "hidden"
 *     Database: "no access"
 */
NONE(0),

/** VIEW permissions.
 *     Presentation: "read-only"
 *     Database: "read access"
 */
VIEW(1),

/** VIEW and POPULATE permissions.
 *     Presentation: "required/highlighted"
 *     Database: "non-null"
 */
REQUIRED(2),

/** VIEW, POPULATE, and DEPOPULATE permissions.
 *     Presentation: "editable"
 *     Database: "nullable"
 */
EDIT(3);

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

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

Ветви:

1) Уровень представления МОЖЕТ скрыть поле (установить доступ к NONE) для указанного в базе данных поля только для чтения (VIEW).

2) Уровень представления НЕ МОЖЕТ отображать поле, когда бизнес-правила говорят, что пользователь не имеет по крайней мере доступа VIEW.

3) Уровень представления НЕ МОЖЕТ переместить доступ поля к «редактируемому» (обнуляемому), если база данных говорит, что это только «требуется» (не обнуляемому).

Примечание: должен быть создан слой представления (пользовательские теги отображения) для визуализации полей путем чтения карты доступа без необходимости каких-либо утверждений "если".

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

(см. Также ветку: Рекомендации по управлению доступом к полям формы )