Как правльно организовать RBAC в данной ситуации?

Question

[vism]

Используется стандартный RBAC
Есть таблица ролей, пермишенов. Пермишены могут быть вложенные(древовидные)
Вводные данные
Стандартный компонент с отображением, редактированием.
Нужно добавить новый пермишен, для определенной роли с возможностью редактировать только 2 поля из более чем 40-ка (manufacturer_order__edit_2_fields)
вот условно дерево пермишенов:

$permissions = [
    'manufacturer_order',
    'manufacturer_order__view',
    'manufacturer_order__edit',
    'manufacturer_order__edit_2_fields',
];

Насколько я знаю, основное правило организации доступа - все запрещено, то что не разрешено.
Поэтому в данные момент существуют проверки на доступ к странице и редактированию по пермишенам view и edit.
Проблема
Условно сейчас для проверки редактирования и отображения полей нужно делать делать проверку для каждого из 40 полей $user->can('manufacturer_order__edit') а для этих двух полей $user->can('manufacturer_order__edit_2_fields')
Тоесть если до этого в коде практически не было проверок, теперь их станет 42 штуки притом их надо сделать как на клиенте(для отображение) так и на сервере для проверки данных
Если в дальнейшем добавятся еще пользователи, которые могут редактировать другие поля - придется добавлять еще проверки и код превратится в

$user->can('manufacturer_order__edit') && $user->can('manufacturer_order__edit_2_fields') && $user->can('manufacturer_order__edit_5_fields')  && $user->can('manufacturer_order__edit_order_fields')

Мне кажется я что-то делаю не так...

Если есть, буду рад ссылкам на статьи или видео с качественным материалом по теме.

UPDATE
это не YII и вопрос не о том как сделать, а как правильно организовать структуру.
Как избежать в отображении десятки проверок, т.к. дополнение и поддержка такого кода будет не приятной, при появлении новых пермишенов

Comments

[Иван Корюков]

А есть ли смысл показывать форму с 40 полями тому, кто может редактировать только 2 из них? У формы с 40 полями наверняка есть какая-то валидация, может быть какие-то побочные действия при сохранении (работа со связанными объектами например). А при редактировании этих двух полей большинство из этого, скорее всего, не нужно.
Кроме того, у новой роли наверняка какой-то свой use case, который можно было бы оптимизировать отойдя от мысли, что редактирование двух полей должно происходить в той же форме что и всех 40. Ну например, можно не заставлять человека заходить на страницу с формой чтобы отредактировать два поля, а вывести таблицу объектов, в которой, в каждой строке, будет минимум информации для идентификации объекта и поля для моментального редактирования. Это конечно, очень зависит от предметной области и от того user story который вы реализуете добавляя роль.

[vism]

Иван Корюков, не, они должны все видеть, но не редактировать.
И потом будут другие сотрудники, с другими полями:)

[Иван Корюков]

vism, ну тогда не вижу другого выхода, кроме как для каджого поля сделать пермишен, и нужным ролям выдавть конкретные пермишены + один пермишен на просмотр формы. Ну а дальше полёт фантизии - городить велосипед чтобы указывать эти данные в одном месте, а работало оно везде)

[vism]

Иван Корюков, Ну вот и у меня так же. Придумать что-то красивое и гибкое не выходит)

Answer 1

[Boris Köln]

Права:

$permissions = [
    'manufacturer_order_add',
    'manufacturer_order_view',
    'manufacturer_order_edit',
    'manufacturer_order_drop',
];

К каждому надо добавить Rule, который будет проверять права (например, проверить статус заказа и что его автор - текущий юзер).

Проверка:

$user->can('manufacturer_order_edit', ['order' => $order])

Подробнее см. www.yiiframework.com/doc-2.0/guide-security-author...

Comments

[vism]

Ну скажет там, не все используют YII :)
Да и вопрос не о том.
Вопрос о кол-ве проверок в коде, для отображения инпутов пользователю и кол-во проверок при сохранении.

[Boris Köln]

Если некоторые поля можно редактировать, некоторые нельзя - тогда на отображение каждого поля нужен отдельный if.

[vism]

Boris Korobkov, Это ад, для проекта с большим кол-ом прав. Понятно что на YII небольшие саас и crm проекты нормально будут себя чувствовать. Но на больших постоянно живущих обычный подход = говнокод. Нужны паттерны проверенные годами поддержки.

Answer 2

[grinat]

Да хоть 3002, эт такое слабое воздействие на быстродействие оказывает, что забей. Лучше подумай о том как добавлять новые поля будешь, например массив полей для которых такая проверка доступна, типа:

const FIELDS = ['field1','filed2'];
foreach(FIELDS as $field){
      if(!$user->can('manufacturer_order__edit_field_'.$field){
           throw new Error('ffdsf');
      }
}

Чтобы ты на клиенте и сервере только в одном месте добавлял новое поле, затем в permission включал разрешение, и вуаля, все работает.

Comments

[vism]

Про быстродействие речи не идет.
Речь о поддержке как-раз и добавлении новых пермишенов на фронте, где происходит отображению пользователю.
Каждый инпут надо оборачивать.

Чтобы ты на клиенте и сервере только в одном месте добавлял новое поле, затем в permission включал разрешение, и вуаля, все работает.

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

[grinat]

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

Каждый инпут надо оборачивать.

И где тут проблема? Ну напиши фабрику, которая будет создавать поля, попутно проверяя пермишены. Что-то типа:

for(var i=0;i<fields.length;i++){
    if(app.can('manufacturer_order__edit_field_' + fields[i].name){
        app.createHtmlTag('input', {name: fields[i].name, value: fields[i].value, class: 'bla-bla'}).insertTo(whereInsert);
	}
}