MVC + arborint skeleton: Access Questions

[ClickHeRe]

Ok, I'm back from a couple months away and I missed the excellent threads on the MVC stuff.

After catching up with all the threads, I have started exploring arborint's code that you can find in this thread http://www.sitepoint.com/forums/show...66&postcount=6

Now the way I plan on working is that the handler is really a page handler and I want to incorporate the path mapping into there so that the front controller only sees the "page" in index.php/page/action/extra/params. He then loads the good page handler (if it exists, all error stuff goes here like the ActionMapper does, which will be a PageMapper in my case). The map is then a parameter of the Page Class and it is mapped against the Request object path using the path mapper type of algorithm. This enables minimal array size for the mapping as the map is only concerned with this particular page's actions and mapped extra parameters.

Now the big question is Access control. I think I will use a User class that will be created at the same level as the Request and Response and sent in the Locator for easy access everywhere (see frontcontroller example code).

The User system has levels (after being authenticated successfully else he's a guest) and permissions. Now the way I see it is that the level part has to be trapped in the front controller to limit access to the page if the person doesn't have suffiscient access rights (admin privilèges for example to the admin section). It could redirect them to an access forbidden page or redirect them to the index page.

The second access type I would like is a user by user case where they can have access to certain actions that must necessarily be intercepted in the PageHandler where the action is dispatched. Again, if insuffiscient privilèges are detected, the user could be redirected to the default action or another page stating, you can't do this, you don't have access.

The problem in both cases is how to map the page/action access vs the user rights/permissions. Re-routing when an access forbidden page/action is selected could be with a redirection to a default page/action.

Also another though in path mapping is what happens if the user types in index.php without a page (execute the default non error page) or uses index.php/page without an action, where it needs to execute the default action (provided that the user has access to the default action which normally he should, because if not, then in theory he should be blocked at page level).

Just throwing ideas around as I haven't had time to get down to it and would like some thoughts on how this could all work together with keeping the basic skeleton code achieved in arborint's archive.

Thanks for any input on the problem of security in those beautiful frameworks.

N.B. I consider myself a noob in frameworks as I haven't built anything myself apart from experimental code in form validators/generators, and an XML/XSLT templating system.

David

[Fenrir2]

I think it isn't a good idea to put something in a framework that can only be used for one thing. Rails uses filters, "hooks" that can be defined for controllers (pages).

class MyController < ApplicationController
   before_filter :authenticate

   def authenticate
       # Authentication code here. This will be executed before any action in this controller
   end

   # ...
end

If you implement it this way your framework will be more "dynamic" because everyone can define his own method of authentication. And filters are useful when you don't have authentication too.

You could put an

redirect_to :action => 'index'

in the authentication method that redirects the user to the index, or you could redirect to a not-authorized page with a link to the login page.

[Dr Livingston]

Also, I have applied the Intercepting Filter to allow for pre and post processing of a given Controller [MVC] which has worked...

I get the impression that where you have the pattern MVC and you need to apply rules - validation for example - you either have the choice of Decorating the Controller in question, or apply the filtering.

With Decoration you get more flexibility but less re-use of code long term, quite the opposite with filtering as I see it

[arborint]

I have only used the code on one small site to see if actually it worked. I did the same thing you did, which is to create an UserAccess object and register it with the Locator. That way it is injected into every dispatched Command and available if needed.

I added some code into the FilterChain in front of the FrontController that checks basic access to actions and changes the action param value to an appropriate error action if denied. That's the front line of Access Control and is how I handled your routing question. You could add the same thing in front of a PageController. This would occur after the PathInfoMapper so the action would already be assigned to a Request var.

Then various pages use the UserAccess object via the Locator for more fine grained control. For example, on an Administration Menu different user types see different composite views.

This code was never meant to be a framework, but more of a code base that you could create your own framework from. I should also not that I cannot take credit for a lot of the good code in there from the Skeleton threads (but you can blame be for the bad code ). There is a more recent version here that adds a file upload example that someone asked for and a little code cleanup.

[arborint]

I think it isn't a good idea to put something in a framework that can only be used for one thing. Rails uses filters, "hooks" that can be defined for controllers (pages).

If you implement it this way your framework will be more "dynamic" because everyone can define his own method of authentication. And filters are useful when you don't have authentication too.

You could put an redirect_to :action => 'index' in the authentication method that redirects the user to the index, or you could redirect to a not-authorized page with a link to the login page.

I'm not sure about not having things that can only be used for one thing? There are lots of thing in frameworks that are very specific use and I don't see a problem with this if the code is clean.

I agree with the "hooks" concept and the code being refered to does allow this sort of thing.

[kyberfabrikken]

I have been elaborating quite a lot on the "skeleton" code since our longest-thread-ever-on-sitepoint-discussion. I deal with authentication in the same way as described, through a filter around the frontcontroller. authorization happens deeper down the application, whenever it's needed. That could be as simple as a second filter around the FC for a application-wide accesscontrol, or it could be within each handler.

I have been toying with a solution where the handlers are created by a factory. This factory could then be equiped with a securitymanager, which could determine if the handler need authorization or not. If it does, it will return a security-decorator wrapping the actual handler. eg :

class ActionFactory
{
    var $securityManager;
    function & createAction($actionName) {
        $this->loadClass($actionName);
        $action =& new $actionName();
        if (!is_null($this->securityManager) && $this->securityManager->isSuspicious($action)) {
            return $this->securityManager->decorate($action);
        }
        return $action;
    }
}

class SimpleSecurityManager
{
    function isSuspicious(&$action) {
        return is_object($action) && method_exists($action, 'isSecure') && $action->isSecure();
    }
    function & decorate(&$action) {
        return new AuthFilter($action);
    }
}
/**
   * @implements IController
   */
class AuthFilter
{
    var $next;
    var $realm = "restricted";
    function AuthFilter(&$next) {
        $this->next =& $next;
    }
    function execute(&$request, &$response) {
        $user =& $request->identity->getUser();
        if (is_null($user->getUUID())) {
            // anonymous user. prompt login
            $response->setStatus(401);
            $response->setHeader("WWW-Authenticate", "Basic realm=\"".$this->realm."\"", TRUE);
            return;
        }
        $this->next->execute($request, $response);
    }
} 

You could rewrite that to replace the factory with a dependencyinjector, especially if you use php5 anyway. (DI and php4 is an odd couple)

[ClickHeRe]

Thanks for the replies, I had thought about the Filtering in front of the controller and I too think it's the best approach since you can add any extra layer over it when needed. How would you suggest saving the mapping between level/page access at front controller level and permission/action at page level ? A registry pattern object (used elsewhere for config matters).

The code was probably never meant to be a framework, but it's still a good start to get on par with the concepts around having a flexible one. Debating is the best part in all these forum posts and will surely help people around in making them better at all this and gving them ideas. I'm not a programmer, so all this is hobby stuff which is why I like it, no pressure and it's fun to learn and will serve me to build my personal sites and PHP projects. I've got a big one that I would like to recode entirely with these concepts to test my personal framework solution.

[arborint]

I have been elaborating quite a lot on the "skeleton" code since our longest-thread-ever-on-sitepoint-discussion. I deal with authentication in the same way as described, through a filter around the frontcontroller. authorization happens deeper down the application, whenever it's needed. That could be as simple as a second filter around the FC for a application-wide accesscontrol, or it could be within each handler.

I have been toying with a solution where the handlers are created by a factory. This factory could then be equiped with a securitymanager, which could determine if the handler need authorization or not. If it does, it will return a security-decorator wrapping the actual handler. eg :

You could rewrite that to replace the factory with a dependencyinjector, especially if you use php5 anyway. (DI and php4 is an odd couple)

I like this idea of having some standard way of adding Access Control. It seems like on the front end (before the FC) that there are a couple of different ways (like Mappers) that you could do Access Control:

1. Simple check such as if user is signed in
2. Some sort of check of the action to allow access to only certain areas (e.g. "admin/*" applies controls to all admin actions)
3. Map based lookup where the access control are looked up based on a map of the actions.

But ultimately some sort of rule based system where you write any Validator Rules you want and add them to the Acces Control Filter that runs before the FrontController. You could then inject that filter with a Locator (which my current fork of the Skeleton uses) or DI, and then apply rules to it for more fine grained view-level control.

[kyberfabrikken]

But ultimately some sort of rule based system where you write any Validator Rules you want and add them to the Acces Control Filter that runs before the FrontController.

At first I tried to mirror the InputValidator class and had an addRule() method in the SimpleSecurityManager class, but I skipped that again.
A better way to go could be to replace the securityManager var in the ActionFactory above with an array. That way you could add several different types of securitymanagers, which each might have different detection-rules (ways to determine if a controller should be wrapped with authentication) and types of authentication (In my example AuthFilter issues an HTTP-auth, but that could be a pretty html-form instead, or a redirect to a loginform or whatever)
You could ofcourse divide it down further, so that the rules were separated from the authtype. Perhaps by passing the authtype as a param to the rule (SecurityManager) ?
That would end up looking something like :

class ActionFactory 
{ 
    var $filters = Array(); 
    function addFilter(&$filter) {
        $this->filters[] =& $filter;
    }
    function & createAction($actionName) { 
        $this->loadClass($actionName); 
        $action =& new $actionName(); 
        for ($i=0,$l=count($this->filters); $i < $l; ++$i) {
                if ($this->filters[$i]->isSuspicious($action)) {
                        return $this->filters[$i]->decorate($action);
                }
        }
        return $action; 
    } 
} 

class SimpleSecurityRule 
{ 
    var $decorator;
    function SimpleSecurityRule($decorator = "HTTPAuthFilter") {
        $this->decorator $decorator;
    }
    function isSuspicious(&$action) { 
        return is_object($action) && method_exists($action, 'isSecure') && $action->isSecure(); 
    } 
    function & decorate(&$action) { 
        $decorator = $this->decorator;
        return new $decorator($action);
    } 
}

...

usage :
$mapper =& new PathInfoMapper();
$mapper->setFactory(new ActionFactory(new SimpleSecurityRule()));
$frontcontroller =& new FrontController($mapper);
$frontcontroller->execute(); 

As for the accescontrol-filter, I put that responsibility in the factory (in a way it's a filter around the factory). I think that makes sense, especially in regards to composite views, since that way you will get the authentication-check even on included sub-controllers deeper down your application. (Given that you use that same factory for instantiating)

[arborint]

At first I tried to mirror the InputValidator class and had an addRule() method in the SimpleSecurityManager class, but I skipped that again.
A better way to go could be to replace the securityManager var in the ActionFactory above with an array. That way you could add several different types of securitymanagers, which each might have different detection-rules (ways to determine if a controller should be wrapped with authentication) and types of authentication (In my example AuthFilter issues an HTTP-auth, but that could be a pretty html-form instead, or a redirect to a loginform or whatever)
You could ofcourse divide it down further, so that the rules were separated from the authtype. Perhaps by passing the authtype as a param to the rule (SecurityManager) ?
That would end up looking something like :

As for the accescontrol-filter, I put that responsibility in the factory (in a way it's a filter around the factory). I think that makes sense, especially in regards to composite views, since that way you will get the authentication-check even on included sub-controllers deeper down your application. (Given that you use that same factory for instantiating)

Are you sure this complexity is needed. It seems like a simple filter with a plugin Rule in front of the Front Controller that rewrote the action param would deal with most every case. The rules could be as simple or complex as needed, and the common rules (e.g. IsSignedIn() ) could be prebuilt.

For any Access Control after the Front Controller things get so appliation specific that Rules would probably be the best solution there as well. I worry about building-in a solution rather than wrapping one around existing simple code.

[kyberfabrikken]

Are you sure this complexity is needed. It seems like a simple filter with a plugin Rule in front of the Front Controller that rewrote the action param would deal with most every case.

I don't really see it as being that complex ? There are two classes involved in the example above - The factoryclass would be nice to have for other reasons aswell, so we really shouldn't count that. That leaves us with just one.

I worry about building-in a solution rather than wrapping one around existing simple code.

I'm actually just extending the mapper a bit, in that I pass a factory to the mapper, rather than let the mapper be a factory as is the case with the original skeleton-thread-code.
As I noted before, I think there may be several benefits of this apart from this access-control thing.

For any Access Control after the Front Controller things get so appliation specific that Rules would probably be the best solution there as well.

I agree that they get very specific, but I don't see how that conforms with rules. As I see it, rules are general in nature, so I'd rather think that the more specific the condition gets, the less appealing it is to describe it with a set of rules. It's far easier to simply let the programmer write a function for each of theese specific cases.

A really nice thing about putting the access-control as a filter in the factory is that it gets decoupled from the actual controller. This makes it easy to change later on.

[arborint]

I have been trying to think through how Access Control works a different levels.

- In the Front Controller it is a filter that changes the action param to a different value based on the what the failure was. It seems more straightforward to me to sit in front of the FC and not get involved in mapping or dispatching.

- For a Page Controller I'm not sure a filter is necessary. It really depends on whether the Page Controller has internal error logic or if it is dispatching sub-contollers. If it has its own error logic then just a straight Validator or Rule will get a true/false for Access Control. Maybe something like you are suggesting would work better if it had sub-controllers.

- Finally for fine grained Access Control within a Controller or View probably just needs a Rule to determine if a specific condition is met.

[ClickHeRe]

At the page controller level, I think there is still a need to have a kind of filter or way to change the action performed if the user doesn't have access to that action (index.php?/page/action/extra parms/...), the same way the page is rerouted in case the user doesn't have access at the page level in the FC.

[arborint]

At the page controller level, I think there is still a need to have a kind of filter or way to change the action performed if the user doesn't have access to that action (index.php?/page/action/extra parms/...), the same way the page is rerouted in case the user doesn't have access at the page level in the FC.

I am assuming that by "page controller level" you mean a controller dispatched by a Front Controller and not an actual Page Controller (no FC). I agree at that level there is often a need to change things based on Access Controls. But that would usually just be part of the Action/Controller selecting a View or a View selecting a sub-View. That's why I think Rules would work best at all levels.

In this Skeleton code, the App Controller is Rule based, so you could add security rules as part of the state/transition logic very easily. For example, the first Rule could be an access check to see if the user is signed or in a certain group -- other presentation rules would follow.

In front of the Front Controller I was thinking of something like this:

// the User class would probably be a gateway to session vars
$UserAccount =& new UserAccount();
// create filter with access to User info
$UserAccessFilter=& new UserAccessFilter($UserAccount );
// go to sign-in page if not signed-in
$UserAccessFilter->addRule(new RuleUserIsSignedIn('signin')); 
// go to error page if not an editor
$UserAccessFilter->addRule(new RuleUserInGroup('editor', 'error'));

// you could execute this before the FC to rewrite the action param on errors
$UserAccessFilter->execute($Locator);
// FC gets passed, default, 'signin' or 'error' action params
$FrontController->execute($Locator);

// or add to a chain with the FC
$HandlerChain->addHandler($UserAccessFilter);
$HandlerChain->addHandler($FrontController);
$HandlerChain->execute($Locator); 

In a Controller or View you could just use the rules

$rule = new RuleUserInGroup('editor', '');
if ($rule->isValid()) {
    // show editor options
} else {
    // no editor options
} 

I'm not sure this is the best way to deal with this, but it would reuse the simple parts (like the Rules and Validator) that the existing Skeleton uses. I think I would need to understand what the common use cases were. Let me know if this makes sense to you -- if so I could maybe create an Access Control example.

[lvismer]

I added some code into the FilterChain in front of the FrontController that checks basic access to actions and changes the action param value to an appropriate error action if denied. That's the front line of Access Control and is how I handled your routing question. You could add the same thing in front of a PageController. This would occur after the PathInfoMapper so the action would already be assigned to a Request var.

I'm trying to understand this approach, would it look something like the following?

$Locator =& new Locator();
$Locator->set('Request', new Request());
$Locator->set('Response', $Response = new Response());
// To use for finer grained access crontol elsewhere in the app
$Locator->set('AppAuth', $AppAuth = new AppAuth());
$Controller =& new FrontController(new ActionMapper('action/', 'home', 'error'));
// To change the current action and redirect to login screen for incorrect authentication
$Controller->addFilter(new FilterAppAuth($AppAuth));
$Controller->execute($Locator);
$Response->out(); 

Many thanks

--
lv

[lvismer]

Apologies Arborint, I seemed to have been busy typing and did not see your last reply. That pretty much awnsers my question

--
lv

[arborint]

Apologies Arborint, I seemed to have been busy typing and did not see your last reply. That pretty much awnsers my question

No, excellent. I forgot to register the UserAccessFilter with the Locator like you did so it is injected into all of the controllers. That would allow finer grained Access Control within the controllers.

[lvismer]

Hi,

Could one not also do the following. Basically my context object is a WebLocator (service locator) with request, response and session objects already set.

The idea is to decorate the FrontController like DL, Kyber and Arborint (etc.) have said in the past to do the initial authentication. At the same time one registers a user access object for fined grained authorization later in the app.

Something like this:

class AppAuthenticator implements IHandler
{
    private $decorator;

    public function __construct($decorator)
    {
        $this->decorator = $decorator;
    }

    public function execute(Context $context)
    {
        // Get a user object and check if the user has been Authenticated
        // The user object will most probably contain some session info and other authorization
        // methods using the rules and validator stuff
        $user = new UserAccess();
        if ( !$user->hasBeenAuthenticated() ) {
            $context->request->set('action', 'Login');
        }

        // Add the user object to the context for using with later Authorization
        $this->context->set('User', $user);

        $this->decorator->execute($context);
    }
}

$fc = new AppAuthenticator(new FrontController(new ActionMapper('../actions/', 'Main', 'Error')));
$fc->execute($context = new Context());
$context->response->out(); 

I am trying to understand all the possibilities.

Many thanks for your comments,

--
lv

[arborint]

Hi,

Could one not also do the following. Basically my context object is a WebLocator (service locator) with request, response and session objects already set.

The idea is to decorate the FrontController like DL, Kyber and Arborint (etc.) have said in the past to do the initial authentication. At the same time one registers a user access object for fined grained authorization later in the app.

My question is: why decorate? If you look at the execution, there is no difference between:

$fc = new AppAuthenticator(new FrontController(new ActionMapper('../actions/', 'Main', 'Error')));
$fc->execute($context = new Context());
$context->response->out(); 

And:

$context = new Context();
$aa = new AppAuthenticator();
$aa->execute($context);
$fc = new FrontController(new ActionMapper('../actions/', 'Main', 'Error'));
$fc->execute($context);
$context->response->out(); 

Except with the second I can put these handlers, plus others, into a HandlerChain and run them all Intercepting Filter style. Plus I have removed a dependency because the AppAuthenticator is no longer dependent on the FrontController. That a few less unit tests.

[lvismer]

<action>... handing arborint a nice cup of coffee ...</action>

My question is: why decorate? If you look at the execution, there is no difference between:

Many thanks, I agree that their is no difference as you have show. I am basically learning here and needed to explore the possibilities, to come to conclusions like you have shown.

Except with the second I can put these handlers, plus others, into a HandlerChain and run them all Intercepting Filter style. Plus I have removed a dependency because the AppAuthenticator is no longer dependent on the FrontController. That a few less unit tests.

Once again, thanks for these insights. To understand, the Intercepting Filter then basically implements a Chain of Responsibility, that gets sequentially executed. The way I see it currently, one could then implement it as a series of decorators or as filters that get executed in sequence?

Apologies if my exploration causes frustration , obviously the reasoning behind the virual coffee.

--
lv

[arborint]

Once again, thanks for these insights. To understand, the Intercepting Filter then basically implements a Chain of Responsibility, that gets sequentially executed. The way I see it currently, one could then implement it as a series of decorators or as filters that get executed in sequence?

Maybe the pattern gurus can help clarify, but here is my take on these patterns.

The Decorator is a way to inject a method into a class to modify it a run-time. It is really the run-time equivalant of "extends".

Chain of Responsibility is an execution chain where the control is in the nodes. Typically each node has a forward() function that it calls to continue the chain or not to stop it. The Chain of Responsibility really an OO switch statement, and to be honest it is often mentioned but I find it as infrequently used as switch statements.

Intercepting Filter is one pattern name that I think is terrible but I can't think of anything better and most everyone (sort of) knows what it means. Intercepting Filter is an execution chain where the control is in the chain manager. Typically every "filter" is executed and it is an object that is passed to each filter that is modified.

I have never really understood the use of Chain of Responsibility with controllers and end up always using Intercepting Filter. The reason is that the end result of any controller is to dispatch, so the last thing in the chain is the dispatcher. With Chain of Responsibility you would need to replicate the dispatcher in every node which goes against DRY.

<action>... handing arborint a nice cup of coffee ...</action>

Apologies if my exploration causes frustration , obviously the reasoning behind the virual coffee.

$response->addContent($template->render('thanks_for_the_coffee.html'))
$response->out();

[DarkAngelBGE]

Christopher, could you maybe explain in some details how the Response and ResponseChild classes are exactly intended to be used? Thanks in advance.

[ClickHeRe]

Here is my code derived from arborint's skeleton code and remodeled in PHP5.

Please feel free to comment, modify it, use it, destroy it, ...

I reused a couple classes and ideas of the skeleton code and changed some parts to fit my needs on the matter.

------------
David