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

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

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание, что ТРЕБУЕТСЯ НЕ является верхним уровнем, как вы могли подумать, поскольку РЕДАКТИРОВАНИЕ (разрешение на заполнение и удаление) является большей привилегией, чем ТРЕБУЕТСЯ (разрешение только на заполнение).

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

/** 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) Уровень представления НЕ МОЖЕТ отображать поле, если в бизнес-правилах указано, что у пользователя нет доступа как минимум на ПРОСМОТР.

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

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

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

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