Hello everybody, thanks a lot for your proposal!
I have a few questions...
0) Should we concentrate first on the Acl component and get it done, then
do the AclTreeTiein?
> (B) Multiple Roles can be assigned to users.
1) I don't want this hard coded, what do you think of quitting
the idea of User/Roles, and consider the Acl in terms of request-objects
(like, a user, or a boat) and ressource-objects (like another object
that the request-object is requesting) ?
Considering only request-objects and ressource-objects, the component
could be very flexible.
Allowing to deal with that with non-oop would simply consist of providing
classes to make string request&ressource objects.
> (D) Permissions are attached to roles. The representation of a
> permission in PHP code is free to choose. Thus a permission can be for
> example just
> a string like 'view' or 'edit', or a structure consisting of an action
> and a section (object to do the action on).
2) I don't want this hard-coded because i want to make custom conditions
to allow the request-object's access to an action with the
ressource-object, do you think that we can use a sort of condition
interface?
This way, we could code our own conditions, the idea seems like
Zend_Acl_Assert_Interface, but without Zend_Acl_Ressource_Interface nor
Zend_Acl_Request_Interface, because we don't want to modify each model
just to use the Acl.
I propose to deal with request and ressource objects from an external
point of view.
For two reasons:
- we don't want to modify each class just to use the ACL with,
particularely if we don't maintain them.
- setting up the Acl, i think, the first thing to do in an application,
although it should be queriable anywhere in the application.
For example::
<?php
$userIdMap = new ezcClassPropertyMap(
'MyUserClass',
'userIdPropertyName
);
$carOwnerMap = new ezcClassMethodMap(
'MyCarClass',
'getCarOwnerId'
);
$hisCarCondition = new ezcAclCallbackCondition(
$equalToCallback, # we'd have factories and stuff like that
array( # using array to evoke unlimited multiplicity
$userIdMap,
$carOwnerMap
)
);
$ruleDriveHisCar = new ezcAclRule(
array( 'drive' ),
array( $hisCarCondition )
);
# (using array to evoke unlimited multiplicity or permissions and
# conditions)
$acl[] = $ruleDriveHisCar;
# way later
$canDrive = $acl->hasPermission(
'drive',
array(
$user,
$car
)
);
# will be true if $user->userId equals $car->getCarOwnerId()
?>
Note that i'm unsure how to deal with the inheritance, but it must be
quite simple since we can add any number of conditions to a rule.
Conclusion:
This component could be really great if it allowed complex rules like in
the example, and if it would supply factories/facades to make inheritence
and string|int request|ressource objects easely.
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
