Где следует выполнять фильтрацию с помощью Acl? - PullRequest
Новая
       5

Где следует выполнять фильтрацию с помощью Acl?

2 голосов
/ 25 мая 2011

Допустим, у меня есть три таблицы: users, books и users_books.

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

. Есть (как минимум) два способа сделать это:

  • В моем методе fetchAll() в модели books выполните join своего рода для таблицы users_books.
  • В плагине Acl сначала создайте ресурс из каждой книги.Затем создайте роль для каждого пользователя.Затем разрешите или запретите пользователям доступ к каждому ресурсу на основе таблицы users_books.Наконец, в методе fetchAll() модели books вызовите isAllowed() для каждой найденной книги, используя текущего пользователя в качестве роли.

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

Что бы вы предложили?

Ответы [ 2 ]

1 голос
/ 25 мая 2011

Я бы отделил ваш код доступа к базе данных от ваших моделей, создав метод поиска в классе репозитория с помощью метода add, такого как getBooksByUser (User $ user), для возврата коллекции объектов книги.

Не совсем уверен, что вам нужны ACL из того, что вы описываете.Возможно я ошибаюсь.

1 голос
/ 25 мая 2011

Я бы запихнул все это в базу данных:

  1. Выполнение этого в базе данных через JOINs будет намного быстрее, чем фильтрация вещей в вашем PHP.
  2. Выполнение этого в базе данных позволит вам правильно разбивать страницы на части без необходимости перепрыгивать через обручи, например, извлекать больше данных, чем вам нужно (и затем извлекать еще больше, если вы в итоге выбрасываете слишком много).

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

Вы можете установить явные ACL в базе данных с одной таблицей вроде этого:

  • id: идентификатор предмета (книги, рисунка, ...), о котором идет речь.
  • id_type: тип или таблица, из которой идет идентификатор.
  • user: пользователь, который может смотреть на вещь.

Пара (id, id_type) дает вам псевдо-FK, который можно использовать для проверки работоспособности вашей базы данных, а id_type можно использовать для выбора класса, чтобы обеспечить необходимый клей для взаимодействия с специфичные для типа части списков ACL и добавление фрагментов SQL в запросы для правильного объединения таблицы ACL.

В качестве альтернативы, вы можете использовать соглашение об именах, чтобы присоединить таблицу вспомогательных таблиц ACL к каждой таблице, для которой требуется ACL. Для таблицы t вы можете иметь таблицу t_acl с такими столбцами, как:

  • id: идентификатор вещи в t (с реальным внешним ключом для целостности).
  • user: пользователь может посмотреть на вещь.

Тогда у вас может быть один класс ACL, который может корректировать ваш SQL с учетом имени базовой таблицы.

Основным преимуществом первого подхода является то, что у вас есть единое хранилище ACL для всего, поэтому легко ответить на такие вопросы, как «на что может смотреть пользователь X?». Основным преимуществом второго подхода является то, что вы можете иметь реальную ссылочную целостность и меньше кода (благодаря соглашениям об именах) для склеивания всего этого вместе.

Надеюсь, что вышесказанное поможет вам думать.

...