MVC vs groups, policies and users.

Расскажите мне пожалуйста, как вы связываете действия контроллера с поведением пользователя?

Гуру Zend приветствуются

12 Responses to MVC vs groups, policies and users.

  1. Kkebad:

    у меня Yii и модуль Yii User Management (Yum).

    помимо стандартного механизма ограничения доступа по экшенам, есть функции типа hasRole() и can(‘someaction’). роли и действия настраиваются в админке Yum (чем-то похоже на друпалово разграничение)

  2. TruYes:

    вопрос не про Zend_Acl, а про то, как его нетривиально использовать. Или не его.

    ,

    с Yii не знаком толком, но
    hasRole(), can() / allow()
    реализовано в Zend_Acl.

    Чтобы эти штуки работали в Zend_Acl, Yum и где-то еще, необходимо задать политики по которым будет происходить проверка.

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

  3. TruYes:

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

  4. Kkebad:

    создаешь роль, ставишь флаг «разрешено членство», заполняешь название и служебное имя.
    потом создаешь действия, их описание и служебные имена. потом через Grant permissions определенным ролям/пользователям даешь разрешения на совершение действий. по сути некая смесь RBAC+ACL

  5. Kkebad:

    а насчет сложности, ну тут видимо сначала нужно смоделировать это все в удобоваримом виде, а потом уже настраивать в системе.

  6. TruYes:

    смоделировать и настроить можно, но если структура потом изменится, то приведение к новому виду существующей модели может оказаться очень дорогой задачей

  7. Kkebad:

    ну кнопку «сделать заебись» для таких задач еще не придумали, к сожалению. не думаю, что структура изменится настолько сильно. все-таки у тебя 99% отражение существующих порядков в организации, а там тоже просто так все с ног на голову не перевернут.

  8. TruYes:

    Есть (в упрощенном виде):

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

  9. TruYes:

    кнопка «сделать заебись» не нужна, так задача мною уже решена, но меня не устраивает решение

  10. Kkebad:

    сколько времени прошло с тех пор, как задача решена?

  11. TruYes:

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

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

    Если с параметрами всё ясно, и ~универсальное решение я придумал, то как быть со смысловыми конфликтами я понять не могу. Как задавать правила, по которым задавать правила

  12. TruYes:

    с момента первого «решения» прошло чуть меньше года, после чего пришлось добавлять новую логику

Добавить комментарий