extend hasPermission without core modification

Is there any way to extend hasPermission without changing the core (to maintain simple upgradeability) ?

For my project, all actions occur in the front-end, using a connector&processors.
In many cases, the existing modx processors (core/model/modx/processors/) are useable "as is" - except the permissions logic.

for example:


Moderators (super users) permissions work fine with the above (they get the permissions in the group, as designed in revo),
but, in addition - each user has the permission to control their own content (edit/delete/etc) - something that is not possible with current revo (maybe 2.1 ?)
A user is considered content owner simply by comparing user->get(’id’) to resource->get(’createdby’).

Currently, I duplicate the modx processor and modify the hasPermission line to fit my needs.
Would be very nice if I could just extend hasPermissions (which would be useful not only for the above case..)

Possible?
Thanks.




Addendum:
I am aware that there also ->checkPolicy , that needs to be taken care of. I assume it and hasPermissions are closely related.
The ideal solution would naturally be from the security side - granting specific permissions for users on the documents they own. but again - this is not possible in 2.0 (i would be happy to find out i’m wrong..)

What an interesting topic you raise here I asked a couple of questions in this forum that might help you, even if it is not exactly the same as you want. To summarize, here is what I found out:

- When creating custom classes with access restrictions, you must implement findPolicy() to provide applicable policies for an object. findPolicy() is used by checkPolicy(). I think the chain is: hasPermission()->checkPolicy()->findPolicy().
- If you want the security model to have automatic owner awareness, you will need to put it into your findPolicy() implementation.

Following this, you could extend modDocument in order to override findPolicy(). This will give you the possibility to add a couple of permissions if user->get(’id’) == resource->get(’createdby’)
- You will of course need to make new documents use your class instead of modDocument.

User-based access policies are planned but not yet implemented. For now you’d have to have a user-specific user group to assign the policy permissions to.

Thanks. For now I would simply implement my own permission check in my processors.
But, as I’m working on a long-term project, and try to stay as compatible as possible with future revisions.
Could you hint on the direction it’s going to be resolved in 2.1?


Thanks

Quote from: oori at Dec 16, 2009, 09:56 AM

Thanks. For now I would simply implement my own permission check in my processors.
But, as I’m working on a long-term project, and try to stay as compatible as possible with future revisions.
Could you hint on the direction it’s going to be resolved in 2.1?

Sure, just by allowing the "principal" in the access control entries to be assigned as a specific User or User Group. Right now it just allows these to be assigned to a User Group, but the access control data structures are already designed to support any "principal" class. There will just be a little additional logic required in the findPolicy() and checkPolicy() implementations to support this. This may make it into a release before 2.1.