Как лучше организовать доступ к элементам класса?

[Adelf]

Духовность™
Почему не может то? Глянь приведенный мною пример. Я не знаю сколько у них сейчас там ролей. Но код "не знает" ничего про конкретные роли и их права. Коду известны только "действия". Права на которые настраиваются отдельно и проверяются не в самом клиентском коде(или алгоритме как тут высказались), а системой. Какие-то возражения против этого подхода? Или я должен был всех этих главных врачей хардкодить?

 

[Gas]

С.

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

$user->haveAccess('resource_id');

нигде в "алгоритме" (раз уж тут пришли к такому соглашению) не должны фигурировать роли, только пользователь и идентификатор ресурса (страница, новость, какой-то блок информации), а правила доступа задаются отдельно. В одном проекте я как-то делал проверки isAdmin(), потом появилась ещё одна роль, потом со временем ещё и пришлось в коде уже ставить isAdmin() && isNewRole(), что конечно полный фейл. Добавление новых ролей не должно вызывать изменение кода, если не появляется новых объектов для контроля.

 

[Духовность™]

Духовность™
Почему не может то? Глянь приведенный мною пример. Я не знаю сколько у них сейчас там ролей. Но код "не знает" ничего про конкретные роли и их права. Коду известны только "действия". Права на которые настраиваются отдельно и проверяются не в самом клиентском коде(или алгоритме как тут высказались), а системой. Какие-то возражения против этого подхода? Или я должен был всех этих главных врачей хардкодить?

ну хотя бы потому, что в коде вполне может быть такой код (он просто делает тоже, что и твой - проверяет роли, просто он обернут в методы is*):

    public function isGuest()
    {
        // У гостей ID модели User всегда меньше 0 (-1)
        // поэтому лезть в базу не обязательно
        return $this->getId() < 0;
    }

    public function isUser()
    {
        if ($this->is_user === null)
        {
            $this->is_user = $this->getGroup() == $this->mapperManager->getMapper('Group/Group')
                                                       ->findGroupByAlias('user')
                                                       ->getId();
        }

        return $this->is_user;
    }

    public function isAdministrator()
    {
        if ($this->is_administrator === null)
        {
            $this->is_administrator = $this->getGroup() == $this->mapperManager->getMapper('Group/Group')
                                                                ->findGroupByAlias('administrator')
                                                                ->getId();
        }

        return $this->is_administrator;
    }

 

[Adelf]

Духовность™
уже говорил - программа программе рознь. В простых веб-проектиках вполне может быть достаточно проверок основанных на ролях. Т.е. метод сам знает каким ролям он доступен. Но этот подход крайне негибок и при малейшем усложнении системы прав требует переработки.
Вот пример попроще: новостной сайт. Новости разделены по категориям. Нужно сделать так, чтобы раздел спорта был доступен только главреду и спортивным журналюгам. И так с каждым разделом. Вводить роли на каждый раздел?

 

[С.]

Кто не хочет прописывать роли в алгоритм, тот будет прописывать каждому юзеру списки resource_id'ов.

Хотя стоп! Это ведь не он будет прописывать, а менеджер. Ну а программер -- весь в белом и умный.

 

[Adelf]

С.
Обычно каждому юзеру - роли. А ролям уже - да. resource_id. Ничего в этом страшного нет. Когда система прав действительно сложна и нуждается в корректировке уже после ввода в продакшен. Не надо звать программистов на каждый чих.

 

[Gas]

Хотя стоп! Это ведь не он будет прописывать, а менеджер. Ну а программер -- весь в белом и умный.

Именно так

Повторюсь, лично моё мнение - "Добавление новых ролей не должно вызывать изменение кода (если не появляется новых объектов/действий для контроля)".

Но по принципу kiss, конечно, можно для простоты начать с проверок isRole() в коде и при необходимости переходить на контроль по ресурсам.
Xотя впоследствии всегда будет проще добавить в несколько мест " && isNewRole()" чем переделвать систему прав, лень она такая, сам знаю )

 

[Вурдалак]

Вот пример попроще: новостной сайт. Новости разделены по категориям. Нужно сделать так, чтобы раздел спорта был доступен только главреду и спортивным журналюгам. И так с каждым разделом. Вводить роли на каждый раздел?

А разве твой подход в идеале это и не предполагает?

 

[С.]

Нельзя написать пользовательскую супер-пупер программу на заказ один раз, а потом все ее поведение настраивать в конфигах.

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

Нельзя перекладывать на пользователя функции ему никаким макаром не подходящие, как то назначение каких-то ненужных и непонятных ему resource_id и т.п.

То что вы видели каки-то такие приемы в CMS общего назначения, не повод вносить их в заказное приложение. Заказчик для того и платит, чтобы приложение работало в привычных ему терминах и ему не требовался бы админ для настройки этого приложения. Иначе это либо недалекость разработчика, либо целенаправленный "развод" заказчика.

 

[fixxxer]

Нихрена вы тут развели из простого примера

ACL - это вполне себе функциональное требование. оно либо есть либо его нет.

Очень редко это действительно надо, в действительно крупных системах. Вот вы часто пользовались виндовым?