CakePHP ACL Aros_acos парадокс

Я пытаюсь реализовать комбинацию аутентификации / авторизации на моем сайте cakePHP с использованием компонентов Auth и Acl, но с моей реализацией происходит что-то странное. У меня есть правильные таблицы acos, aros и aros_acos, и они, кажется, работают на каком-то уровне.

Я нанес на карту свои действия следующим образом:

$ this-> Auth-> mapActions (array ('read' => array ('view'), 'update' => array ('edit')));

Моя таблица acos выглядит так:

    1. Site
  • 1.1 Страницы
  • 1.2 Пользователи
  • 1.3 Группы
  • 1.4 Администратор

и таблица арос:

    1. users
  • 1.1 редакторы
  • 1.1.1 админы
  • 1.1.1.1 admin_name
  • 1.2 обычный_пользователь

Пользователи, редакторы и администраторы - это группы. Admin_name - это пользователь с правами администратора, член группы администраторов, а regular_user - член группы пользователей.

Теперь, в таблице aros_acos, если я дам группе 'users' права CRUD для 'страницы' следующим образом: 0 1 1 0 (что дает им право читать и обновлять), тогда все работает нормально (по крайней мере, для ' просмотр и редактирование действий). Но если я поставлю 0 1 0 0 (только право на чтение), то меня перенаправят на '/', и я заметил одну особенность: он не вызывает app_controller или, по крайней мере, функцию beforeFilter () в app_controller.

Более того, я написал beforeFilter (), чтобы, когда пользователь не имеет доступа к crud, выдавать ему флэш-сообщение $ this->, давая ему знать, что он «не авторизован» (мне пришлось сделать это , поскольку $ this-> Auth-> authError, похоже, не работает). Итак, имея это в виду, я теперь переписываю таблицу aros_acos для группы пользователей следующим образом: 0 0 1 0 (разрешение только на обновление), и на этот раз я получаю флэш-сообщение, когда получаю доступ к действию 'view' (что правильно поскольку у меня нет разрешения на доступ к нему), но я также получаю флэш-сообщение, когда пытаюсь получить доступ к действию «редактировать».

Я что-то упускаю и не знаю что. Я написал этот вопрос, надеясь, что, прежде чем закончить, сам придумаю решение ... но не повезло. Я до сих пор не знаю, что происходит, думаю, это какая-то штука с контроллером ... Есть идеи?


person Progenitura    schedule 08.09.2009    source источник


Ответы (1)


Мысль 1 -> У вас где-то на странице просмотра случайно есть requestAction на другую страницу? Он может поступать со страницы просмотра или элемента на странице просмотра.

Мысль 2 -> Создайте свою полную карту действий. Возможно, это не проблема, но лучше начать с этого.

$this->Auth->mapActions(array(
'read'=>array('index','view','admin_index'),
'create'=>array('add','admin_add'),
'update'=>array('edit','admin_edit'),
'delete'=>array('delete','admin_delete')));

Не бойтесь при необходимости отследить код до компонента Auth. Просто пройдите (), пока не найдете, куда он перенаправляет. Выясните, в чем конкретно заключается проблема.

Убедитесь, что ваш сеанс правильный и не изменится в процессе.

Мысль 3 -> Правильно ли вы «перестраиваете» таблицы acl? Это может быть проблема с данными. Я бы посоветовал вам использовать функции createAco (), createAro () и $ this-> Acl-> allow (), чтобы убедиться, что данные верны и все ключи верны. (никогда не помешает проверить)

Это одна из тех проблем, по которым вам нужно пройти шаг за шагом и отследить через приложение. Я использую текущий стабильный CakePHP и не обнаружил никаких проблем.

person Dooltaz    schedule 09.09.2009
comment
Спасибо за ответ. В последние дни я пытался отследить свою проблему, но так и не смог ее найти. Итак, в конце концов, я как бы поправил это с помощью линии разводки. Итак, теперь я перенаправляю '/' на страницу входа. Вроде работает. Я не знаю, подходит ли мое решение, на самом деле я почти уверен, что это не так, но в любом случае у меня есть крайний срок, и это решение работает на всех уровнях (что я тестировал). Теперь, если пользователь пытается получить доступ к неавторизованному crud, он отправляется на страницу входа и на этой странице получает уведомление $ this- ›Auth-› authError. В любом случае спасибо за поддержку. - person Progenitura; 11.09.2009