Question

I’ve developed a small yet effective MVC-style framework for use in an application, and I’m implementing an ACL per-request check.

Quick details: PHP 5.3+; MySQL 5.1+; Custom framework, “MVC-like”

As of now, the ACL check is simple “deny-if-not white-listing“; Each group can be assigned permission to certain request handlers. For example:

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 and group excluded for brevity, but their models are nothing unusual)

Anyways, my framework routes URIs to the appropriate handler_key via a handler/path table (to decouple the filesystem architecture) The request is then dispatched to the handler, given the group_id associated with the request is white-listed for that handler_key.

I’m curious, what is the best approach to implement storing/checking arbitrary (user-defined) constraints? Case examples would be:

• Only permit the given group to invoke a handler weekdays, between 8:00 and 17:00.
• Only permit the given group to invoke a handler to modify “owned” data; ie: data created by the associated user. This check would involve perhaps, a check of the user_id field associated with the content to be modified by the handler, and the user_id associated with the request

I had a flags column, however that is not future-proof with the introduction of more feature, group, and constraint requirements. I was thinking in the following direction, but what to use?

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

---

Unnecessary clarification:

(Note: code was typed here, not copypasta from project)

To clarify some of the jargon here; handlers (specifically web handlers) are essentially controllers, for those familiar with the MVC archetype.

Their specific implementation is a single PHP file, which returns a function to be called by the dispatcher, or sub-handler caller. For example:

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

My framework uses web handlers and API handlers; web handlers feed data into a response object (basically a collection of hierarchical views) which generates HTML. The data is obtained by invoking the API handlers, which simply return raw data (API handlers could be regarded as representations of the model, going back to typical MVC)

Compound handlers are essentially an abstraction layer, as they are handlers themselves that invoke handlers to aggregate data. My current implementation of the ACL check, does a cursory check of all nested handlers (via $meta, an array variable declared to act as the metadata header for the handler) For example:

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

Answer 1

After having reviewed my architectural choices, it became apparent to me that I could take advantage of my handler style request-handling approach.

(Please, critique and/or ridicule and/or high-five this proposition as warrants)

A request to check if a user has permissions can, for these purposes, be seen as simply another request, therefore requiring it’s own handler. For example:

permission
+---------------+--------------------------------------+- - - - - -+
| permission_id | handler_key | constraint_handler_key | arguments :
+---------------+-------------+------------------------+ - - - - - +
|       1       | lorem_ipsum | user_check_owner       |           :
|       2       | hello_world | user_check_owner       |           :
|       3       | foobar      | time_check             |           :
+---------------+-------------+------------------------+ - - - - - +

With the addition of a NULL-able constraint_handler_key column, new constraints can be programmatically created, and administratively delegated.

When a request fires, the framework aggregates the handler chain, and compares it against the white-list, as it already does. In the event a constraint_handler_key exists (possibly with arguments as the above table suggests) it performs a look-up in the handlerTable associated with that request type:

// web handlers handlerTable example
return array(
    'lorem_ipsum' => PATH_WEB_HANDLERS . 'path/to/lorem_ipsum.handler.php',
);

// acl handlers handlerTable, follows same format
return array(
    'time_check' => PATH_ACL_HANDLERS . 'time/check.handler.php',
);

(API handlers are also identical)

The ACL handler is expected to return only boolean values, thus continuing or ending the permissions check sequence, and therefore, the whole request.

// time_check acl handler, allow if current time between 9am - 5pm
return function($request){
    $dayBegin = time() - (time() % 86400);
    return (time() > ($dayBegin + 32400) && ($dayBegin + 61200) > time());
};

Cases of the omission of constraint_handler_keys are handled as basic white-list checks; allow-if/deny-if-not.

So my application directory will start looking like this:

:
+- application/
|   +- config/
|   +- views/
|   +- handlers/
|       +- acl/
|       +- api/
|       +- web/
: