Распределение доступа CakePHP при доступе к данным на основе ролей

Question

Требования к моему проекту выглядят примерно так:

Наверху будет администратор, у которого будет полный доступ, первый уровень

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

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

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

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

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

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

Я могу работать, настроив компонент ACL по умолчанию, но это займет больше времени, чем ожидалось.

Приветствуются любые лучшие идеи / предложения!

Answer 1

На мой взгляд, ACL не так уж и волшебен. Например: ACL может управлять разрешениями, чтобы указать, кто имеет доступ для добавления / редактирования / удаления продукта .. но он не сможет изменить запрос для фильтрации продуктов в соответствии с определенными разрешениями (например, «пользователи из отдела A могут только см. продукты из отдела A ") ... ну на самом деле это ложь, ACL может справиться с этим, но это может быть непрактично, потому что каждый раз, когда вы добавляете продукт, вам придется создавать ACO и устанавливать разрешение в таблице AROS_ACOS и поскольку AROS представляет собой древовидную структуру, она может легко превратиться в кошмар, если вы планируете запрашивать свои данные

Я бы использовал ACL только для группы для управления доступом к определенным страницам / действиям и создания таких правил, как:

• "Начальник отдела может получить доступ к странице 'список продуктов' и добавить / удалить / изменить продукты "
• "Администраторы могут получить доступ все страницы »
• "Другие пользователи могут получить доступ "список продуктов", и они могут добавить продукты, но не удалять их "

и я бы скорректировал свои запросы в соответствии с подключенным пользователем, поэтому в контроллере страницы «список продуктов» я бы сделал что-то вроде:

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

если у вас слишком много запросов и вы не хотите выполнять тысячи предложений if, вы можете создать компонент, поведение или, возможно, расширить метод product.department_id=connected_user.department_id в find() . Идея состоит в том, чтобы перехватить все запросы и проверить, есть ли в одной из моделей, используемых в запросе, поле с именем «Department_id», если они есть, тогда добавить в запрос условие app_model.

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

Удачи!

ИЗМЕНИТЬ: я использую следующее поведение:

родовое слово

На самом деле это довольно просто. Я изменяю запрос, добавляя условие, соответствующее текущему языку ($ _SESSION ['lang']). В контроллере все, что мне нужно сделать, это прикрепить LocalizableBehavior и использовать метод find как обычно:

родовое слово