Реализация ограничений ACL, более чем разрешить/запретить

я разработал небольшую, но эффективную структуру MVC-стиля для использования в приложении, и я реализую проверку ACL на запрос.

быстрые детали: PHP 5.3+; MySQL 5.1+; Custom framework,"MVC-like"

на данный момент проверка ACL проста "запретить, если не белый список"; каждый group можно назначить разрешение определенным обработчикам запросов. Например:

privilege                       permission
+----------+---------------+    +---------------+---------------+
| group_id | permission_id |    | permission_id | handler_key   |
+----------+---------------+    +---------------+---------------+
|     1    |       1       |    |       1       | lorem_ipsum   |
|     1    |       2       |    |       2       | hello_world   |
|     2    |       3       |    |       3       | foobar        |
+----------+---------------+    +---------------+---------------+

(user и group исключены для краткости, но в их моделях нет ничего необычного)

в любом случае, мой фреймворк направляет URIs в соответствующий handler_key через таблицу обработчика / пути (для разделения архитектуры файловой системы) запрос затем отправляется обработчику, учитывая group_id связанный с запросом белый список для этого handler_key.

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

• разрешить данной группе вызывать обработчик только в будние дни, с 8: 00 до 17:00.
• разрешить только данной группе вызывать обработчик для изменения "принадлежащих" данных; т. е.: данные, созданные связанным user. эта проверка будет включать, возможно, проверка user_id поле, связанное с содержимым, которое будет изменено обработчиком, и user_id связанные с запрос

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

permission
+---------------+----------------------------+
| permission_id | handler_key   | constraint |
+---------------+---------------+------------+
|       1       | lorem_ipsum   |     ?      |
|       2       | hello_world   |     ?      |
|       3       | foobar        |     ?      |
+---------------+---------------+------------+

ненужное уточнение:

( Примечание: код был набран здесь, а не copypasta из project)

чтобы прояснить некоторые из жаргона здесь;обработчики (в частности, веб-обработчики) по существу контроллеры для тех, кто знаком с архетипом в MVC.

их конкретная реализация представляет собой один PHP-файл, который возвращает функцию, вызываемую диспетчером или вызывающим суб-обработчиком. Например:

<?php
    $meta = array('subhandlers' => array());
    return function($request, $response) use($meta){
        $response['foo'] = 'bar';
    };

мой фреймворк использует веб-обработчики и API-интерфейс обработчиков; веб-обработчики передают данные в объект ответа (в основном набор иерархических вид), который генерирует HTML. Данные получены путем вызова обработчиков API, которые просто возвращают необработанные данные (обработчики API можно рассматривать как представления модель, возвращаясь к типичному MVC)

составные обработчики по существу являются слоем абстракции, поскольку они сами являются обработчиками, которые вызывают обработчики для агрегирования данных. Моя текущая реализация проверки ACL делает беглую проверку всех вложенных обработчиков (через $meta массив переменная, объявленная в качестве заголовка метаданных для обработчика) например:

<?php
    $meta = array('subhandlers' => array('my_subhandler'));
    return function($request, $response) use($meta){
        $someData = Caller::call('my_subhandler', array($request, $response));
        $response->bind($someData);
    };