Zeta 3 - облегченное управление правами на выполнение операций

Проблема в Zeta2.
В Zeta2 присутствовал гибкий механизм определения прав доступа на выполнение операций, централизованный с общей системой безопасности на основе токенов. При крайней гибкости данного решения, оно не оправдало себя:

1. Было неудобно в разработке, 90% случаев решалось через атрибуты Admin, Public, Role и миновало ACL
2. Низкая производительность
3. Крайне неудобно для админов, так никто из действующих админов не научился писать правила доступа к веб-коммандам.
4. Не востребованным оказался механизм предпроверки параметров - все равно параметры по безопасности потом приходится проверять в коде.
5. Много внимания было уделено всяким непроизводительным резольвингам динамических действий и асинхронных методов, хотя на практике не пригодилось

Соответственно в Zeta3 подход пересмотрен.

1. Оставлен только механизм на основе ролей и атрибутов контроллера Roles и его упрощенных форм Public, Admin
2. Механизм арсширен за счет СПЕЦИАЛЬНЫХ РОЛЕЙ при помощи которых администратор может провести "тюнинг" доступа - это на смену ACL
3. Доступ по умолчанию сменен на ОТКРЫТЫЙ, ранее было ЗАКРЫТЫЙ - неудобно при формировании малых приложений и виджетов

Обзор

Для разработчиков

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

Помним, что по умолчанию контроллер, действие ДОСТУПНЫ, а ADMIN будет иметь доступ независимо от настроек

[Roles("r1,r2")] - элемент доступен администратору, и ролям r1 и r2 (любой из них)

[Admin] == [Roles("ADMIN")]

[Public] == [Roles("DEFAULT")]

• Если и у действия и у контроллера указан атрибут - то используется настройка действия
• Если у контроллера есть атрибут, а у действия нет - используется атрибут контроллера

[Controller]

[Admin]

class controller1 :

          [Public]

          def action1() :

                   pass

controller1/action1 - доступен всем

[Controller]

class  controller2:

          [Admin]

          def action1() :

                   pass

           def action2():

                   pass

controller2/action1 - доступен только админам

controller2/action2 - доступен всем

Для администраторов

Нужно знать имена контроллеров и действий, или хотя бы уметь определять их по URL, так в адресе http://myserver/myapp/zeta/start.rails - ZETA - имя контроллера, START - имя действия
Из названия контроллера и действий можно делать СПЕЦИАЛЬНЫЕ РОЛИ:

1. Разрешающая роль уровня действия - допустим есть команда execute, контроллера tasks, доступная только админам, а надо дать постоянный или временный доступ именно к этой команде пользователю domain\user1, в этом случае в файле привязки ролей можно написать map "domain/user1", "ALLOW_TASKS_EXECUTE"
2. Разрешающая роль уровня контроллера (группы комманд) - задача аналогичная предыдущей, но роль чуть другая map "domain/user1", "ALLOW_TASKS"
3. Запрещающая роль уровня действия - допустим есть контроллер form, имеющий метод addattachment  для добавления приложений, form доступен всем членам роли OPERATOR. Вы хотите чтобы пользователь  domain/user1 не теряя доступа в целом к операциям формы не имел права добавлять приложения, в этом случае поместите его в роль  map "domain/user1", "DENY_FORM_ADDATTACHMENT"
4. Запрещающая роль уровня контроллера - та же мотивация, только более широкая область запрета map "domain/user1", "DENY_FORM" - запрет доступа ко всем операциям контроллера FORM

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