Design an ApplicationController implementation together

[nacho]

I've mentioned this before, but what about this - not hypothetical - situation:

- a user can only edit a news article when he has posted that article himself. In other words $user->id == $news->userID.

How do you fit that in with your three things needed for Access Control, arborint?

I like you mention this because it has had me going nuts for a while in the past. I've never implemented myself but I came up with an idea I think you'd like

Considering a RBAC system, each role is in fact a group of users. Within each, I'd define a captain (I said you'd like it) who has the privilege of performing actions on each and every object created by any other user in that group (of the same role) or any group below it (groups/roles keep hierarchical order). By default a user can/may only perform actions on the items he/she him/herself created. By default every first user of a group is captain. Of course, multiple captains would also be possible; that way you could define a role (visitor) which has privileges to perform an action (read) on a given object (article) where every user is a captain ...

Does that make any sense?

[cryonax]

Besides, actions should also be known beforehand so they can be mapped, and business objects (objects upon which an action is performed) should probably be hierarchichal in a way that if the object above the hierarchy does not allow an action you should not have to look any further.

In this case actions should also be hierarchical (or at least the authorizer should be able to establish a hierarchy). It should be possible to define required credentials for a connected group of actions as a whole.

[nacho]

In this case actions should also be hierarchical (or at least the authorizer should be able to establish a hierarchy). It should be possible to define required credentials for a connected group of actions as a whole.

IMO there is no such a need. Actions are mapped to objects which are hierarchical, i.e. if a user does not have the privilege to read a thread, he/she won't have the privilege to read a post belonging to that thread. The action (read) is for both objects the same.

[arborint]

I've mentioned this before, but what about this - not hypothetical - situation:

- a user can only edit a news article when he has posted that article himself. In other words $user->id == $news->userID.

How do you fit that in with your three things needed for Access Control, arborint?

I agree that this is a case. That is why I asked my questions, because there is not just on answer for each. I think you are right that at what is probably the View level there is sometimes a need for Access Control. In that case the View would probably need to call a method in the Controller or Model such as hasAccess(array('admin','artist')) (please note that is is example code and I am not prescribing an Access Control system). The access data could come from the Front Controller passed to the Controller or set in the Controller itself.

What we need is a system that can pass access control data through the controllers to provide hasAccess() or isSecure() calls. Any controller along the way should be able to set the access data so the system is flexible. That is #1 in my list above.

What I am wondering is what are the common combinations, meaning where the access data is set and where it is used. If there are only a few "real" combinations it may simplify the code as opposed to having to handle every permutation.

[Dr Livingston]

Did you had a look at my code I posted above

Yes I did have a look at it, and for the most part I gained a general idea of what the script does, but it is not recursive? I note the DEFINEd constant which signifies that there is no parent nodes... Which may account for the lack of recursion, of which you actually may not have the use for it I'm pondering

Within each, I'd define a captain (I said you'd like it) who has the privilege of performing actions on each and every object created by any other user in that group (of the same role) or any group below it (groups/roles keep hierarchical order).

I like hierarchacal structures, and as such I for the most part base my design around this. So, for each folder that there is, it has a Controller file yes? Well, also inside this folder is a small XML configuration file which holds the groups, their users and their (users) roles that they have assigned to them (for that given Controller, and nothing more).

This makes a lot of sense (to me), and makes my life a lot easier in regards to implementation, as the whole lot is based on the Composite anyways. A Visitor is used to access any or all Composites, and in doing so, the Visitor will also fetch, parse and validate the credentials of the user, against the Controller in question.

Hope this gives you some clues anyways?

[Captain Proton]

..I'd define a captain (I said you'd like it)

hehe Loving it already

In that case the View would probably need to call a method in the Controller or Model such as hasAccess(array('admin','artist'))

The view that displays a listing with edit links would need something like that. The Edit Controller would need to perform the check itself and redirect to some unauthorized page.

What we need is a system that can pass access control data through the controllers to provide hasAccess() or isSecure() calls. Any controller along the way should be able to set the access data so the system is flexible. That is #1 in my list above.

How about something as simple as this:

class MyCommandOrControllerOrWhatever
{
function execute()
{
// load some stuff here
if (!$news->userID == $userID)
{
$this->redirectToUnauthorizedView();
}
...
}
}[/quote]

[arborint]

I was thinking of something like the following where the Front Controller of any succeeding controller could install an Access Handler and the controller would proxy the call to the installed Access Control code. We could add something like these methods to all controllers:

class BaseController {
... // all the common controller stuff

    function setAccessHandler($obj) {
        $this->accessHandler =& $obj;
    }

    function hasAccess($value) {
        if (isset($this->accessHandler)) {
            return $this->accessHandler->hasAccess($value);
        } else {
            return true;
        }
    }

} 

Here is a simple example of an Access Handler for giving access if the user is signed-in:

class SignedInAccessHandler {
... // all the common controller stuff

    function SignedInAccessHandler() {
        $this->user =& User::getInstance();
    }

    function hasAccess($value) {
        return $this->user->usSignedIn();
    }

} 

[Captain Proton]

Well, the problem is, at least that's the way I see it, that in general it it can not be known if a user is authorized to perform some action until you're at the level of the Action object. This news user ID example I gave is proof of that. There is no way that an object at the same level of the FrontController or any other layer 'above' the Action can give or deny access.

[Dr Livingston]

// ...
 if (!$news->userID == $userID)
{
// ... 

What if... What if, instead of performing the comparison of one ID against another ID, of which you'd need to define anyways, you just passed in the News object it's self, to another object that would represent the user?

If there was a common Interface, this would obviously make it more flexible as well. That way, the logic would remain where it's supposed to be, and not in the client script that requires the verification of the action?

// ...
if( $user -> verify( $news ) ) {
// ...
} 

Umm...

class BaseController implements ... {
public function __construct() {}
public function isSecure() {
return true; // public access
}
// ...
} 

This looks from my point of view, to be a better deal? But maybe that is just me, since I use a lot of configuration, so I can't (or don't?) see the need to have the approach that your suggesting.

The problem for me is when you need to take another approach to validate the requested action against the user, and the Controller in question has no real control or say so of what can or cannot be done? For example, you are passing in the Access Handler class which has a very specific responsibility?

But what if there was to be an additional responsibility that was to be taken into consideration, which is outside the Access Handlers scope... Maybe I'm just feeling itchy huh?

[Captain Proton]

If there was a common Interface, this would obviously make it more flexible as well. That way, the logic would remain where it's supposed to be, and not in the client script that requires the verification of the action?

Sure, that is perhaps a better way to implement the actual verification, but it is totally unrelevant.

The problem is that it is unknown which data (domain model data if you like) is needed to verify that a user has access until you are 'in' the actual Action.

[arborint]

Well, the problem is, at least that's the way I see it, that in general it it can not be known if a user is authorized to perform some action until you're at the level of the Action object. This news user ID example I gave is proof of that. There is no way that an object at the same level of the FrontController or any other layer 'above' the Action can give or deny access.

This is actually not true for the 'skeleton' Front Controller because if you use the LookupMapper you can include data for each action in the map. This data could include the minimum access privileges necessary to access the action. The Front Controller could check the access data returned by the mapper and only dispatch the action if the hasAccess() succeeded (i.e. check to see if the user privileges stored in the session meet the access privileges for the action).

I think one if the interesting ideas in this is rather than have a controller check to see if the user has access, the the parent controller could check if access is allowed (by calling a method in the child) BEFORE dispatching the controller's execute() method.

[arborint]

The problem for me is when you need to take another approach to validate the requested action against the user, and the Controller in question has no real control or say so of what can or cannot be done? For example, you are passing in the Access Handler class which has a very specific responsibility?

But what if there was to be an additional responsibility that was to be taken into consideration, which is outside the Access Handlers scope... Maybe I'm just feeling itchy huh?

I'm not sure I understand "if there was to be an additional responsibility that was to be taken into consideration, which is outside the Access Handlers scope"? I am assuming that you could just add features to the Access Handler as needed. How is it different from any other way?

The goals of the code I presented was:

- to allow plugin Access Control handlers so we don't dictate what is used.

- to have the Access Control object was passed through the controllers so it was available at any point

- the calls were the same even if the data passed was different for different Access Control handlers.

- hide things like the $user object from the action to keep the code focused

[Captain Proton]

This is actually not true for the 'skeleton' Front Controller because if you use the LookupMapper you can include data for each action in the map. This data could include the minimum access privileges necessary to access the action. The Front Controller could check the access data returned by the mapper and only dispatch the action if the hasAccess() succeeded (i.e. check to see if the user privileges stored in the session meet the access privileges for the action).

Sounds very complicated. What if the decision to give or deny access depends on a lot more parameters? A user that can only edit if he has edited 10 other items in the past, has at least 12 kudos and has a valid e-mail

I know that sounds rediculous but I'm sure you see the point. But if you feel confident that you can support something like this elegantly, by all means do so

[arborint]

Sounds very complicated. What if the decision to give or deny access depends on a lot more parameters? A user that can only edit if he has edited 10 other items in the past, has at least 12 kudos and has a valid e-mail

I think maybe there is some overlap between access and capabilities. They are conceptually the same thing by are handled differently the same. Take your example "A user that can only edit if he has edited 10 other items in the past, has at least 12 kudos and has a valid e-mail." Access control would handle if they could actually access the Editor page based on their user account. Once they are on the Editor page there may be additional restrictions, but I think those would be handled by the Editor page's Model, not a central Access Control system. Does that make sense to you?

I know that sounds rediculous but I'm sure you see the point. But if you feel confident that you can support something like this elegantly, by all means do so

I don't think I can support all Access Control possiblities out there, or even come close. But I do think that the common level, group and role based Access Control schemes can be handled in a straightforward way.

[wdeboer]

Yes I did have a look at it, and for the most part I gained a general idea of what the script does, but it is not recursive? I note the DEFINEd constant which signifies that there is no parent nodes... Which may account for the lack of recursion, of which you actually may not have the use for it I'm pondering

Well, it does.. but because in the above example I am taking a node and strip out all child nodes which aren't of specific types I only want site elements, not pages, or sites users etc. Just the page and the components of this page such as articles, and such kind of things. This is way I am filter thosen odes, because I only want the nodes and the properties of it to use in the page.

One of the reason why I don't use recursion in this example. If you happen to know a better way to deal with this don't hesitate to share your knowledge with me.

I still need to do the authorization/authentication part of the system, because I would like to inherited the permissions from the parent node. If the parent node doesn't have the apporiate rights (i.e. no read rights -> meaning accessible) then it should etc. I am planning to define a basic set of permissions for objects/node types in a configuration file, which can then be overriden through settings on a per user/role/object instance and object property base. That's the idea atm

[wdeboer]

Hello! I have been busy using this ApplicationController design of you guys, it works quite well. Only I have one question how can I make wizard-type forms? Because I have form that's so huge (10 A4 pages, don't ask me <g>) that I want them to be spread over multiple pages. Now did I found the InputController example, only this only has a initialize, invalid and done page. While I want 10 groups.What would be the best way to make this? Shall I extend the current InputController with some sort of state machine, but how should I store the data of the previous groups/pages? I could store them als a temproaly item in the database, if anyone has any adivce.

Please let me know I am a bit clueless for now.

[nacho]

Hope this gives you some clues anyways?

Well, to be honest I'm not so crazy about using XML really, but that's rather a matter of implementation.
You did give me a nice idea about grouping users around a certain section of the application (which I call module) instead of coupling users to the top level. That would give me much more freedom probably, but I'll have to study it first.

Overall though, I see now (I've had a quick look at what you guys have coded so far) that my "solution" about handling privileges and actions (despite the fact that Captain Proton liked the use of captains) does not fit well into your application design. The reason mainly being that I don't treat "actions" as you do. To me, an action is generic and independent of the object it acts upon. For instance, a CRUD system would have 4 different actions for me, create, read, update and delete. A request defines, the way I see it, an action, an object type and an object identifier, so a possible request would be something like read page home, being read the action, page the object type and home the object identifier (in this case an unique title). As you see, quite different approach.

Could somebody tell what the general objective of this Application Controler is? Are you planning to build web applications with it (or is it just an exercise), and if so, what kind of applications (I already have a good idea of course but it would be nice if you define some context or constraints for the application)?

It's KISS been taking into consideration or it's MVC structure more important?

[wdeboer]

Well, I would like to build web application with it, such as a POC of my management system, and my online forms full in application for internal use.

[Captain Proton]

Does that make sense to you?

Yes, it does.

[kyberfabrikken]

well, let's keep focus here. Authorization is highly dependent on the requirements of the application. Some applications may work well with authorization happening at the controller-level ( ~ isSecure()), while others may need it to happen at a lower (model-layer) or higher (frontcontroller) level. What they all have in common however, is that they rely on a authentication happening beforehand. This is fairly generic, and I suppose it could happen as an intercepting filter in the frontcontroller.
I suspect that putting together a general method of authorization is just not possible, or if it is, it will be very complex and thus overkill for most applications. I'd like to be proven wrong though.

In that case the View would probably need to call a method in the Controller or Model such as hasAccess(array('admin','artist'))

A way to handle authorization at the controller-level, could be through the applicationcontroller. By providing a Rule which validates against what-ever restrictions you may have (such as user belonging to a certain group), it could be solved with the code we already have. Eg :

class SecureAction 
{
    function SecureAction(&$action, &$deniedAction) {
        $this->controller =& new FlowController($action, $deniedAction);
        $this->controller->addRule(new Rule_UserGroup(Array('admin', 'artist')));
    }

    function execute(&$context) {
        $this->controller->execute($context);
    }
}

class MySecureAction extends SecureAction
{
    function MyAction () {
        parent::SecureAction(new MyAction(), new 403Action());
    }
} 

(Could probably be simplified a bit, but you get the point, I suppose)

[nacho]

Well, I would like to build web application with it, such as a POC of my management system, and my online forms full in application for internal use.

Could you be a little more specific? (POC=Point of Contact?)

[wdeboer]

Proof of concept

[Ezku]

Might be a bit late at this point, but I'm beginning to wonder how you actually relate a field with an occurred error. The Logger doesn't support identifiers of any kind, so how do you take a Logger and fetch an error for Field_Foo? I can only come up with having the Rules log Errors that support some kind of identification mechanism, but that would still mean having to iterate through $logger->getMessages() at some point or another.

[kyberfabrikken]

Might be a bit late at this point, but I'm beginning to wonder how you actually relate a field with an occurred error. The Logger doesn't support identifiers of any kind, so how do you take a Logger and fetch an error for Field_Foo? I can only come up with having the Rules log Errors that support some kind of identification mechanism, but that would still mean having to iterate through $logger->getMessages() at some point or another.

Well. Not all errors does relate to a field. Most does though. I didn't really solve that problem, but one way would be to log an object, rather than a string. This object would contain the message aswell as the name of the related field.

[Ezku]

That's what I meant with logging Errors. Notice the capitalization.