Forum OpenACS Development: Re: Permission system in needs of revisit?

14: Re: Permission system in needs of revisit? (response to 5)

Posted by Malte Sussdorff on 09/08/07 07:35 AM

I agree that proxy objects are great. I am wondering though if we want to give permissions per object type if we should not provide an easier method than using the query-writer approach by "just" making object_types objects.

I am now faced with the situation that I need to give permission to create various object types through an external interface. The only requirement is that the users can create, write and delete (for the sake of discussion) "tasks, projects,files,comments". Write and delete is a piece of cake, though it implies to either be stuck with a lot of entries into the permission table or to group them into proxy objects / roles in the code.

But what should I do with create? Here I need the proxy object, because I cannot give create permissions on a not yet created object. We could argue to say that "if you have create permissions on the context_id then you are allowed to create the object". But is this right? And wouldn't I still have to check if I am allowed to have write permission on the object_type?

This being said, it can all be done with the existing permission system and making object_types objects has nothing to do with it. But I am still unsure how "create" should behave 😊.

Now to something more interesting:

Assuming object_types are objects (or I use rel_segments), if I have read access to an object_type (rel_segment) I have access to the object of that type if I have access to the context_id. Meaning: If I have read access on tasks in general, I am able to view a task if I have read access on the project.

I will ponder about this a little bit more while working out how to map an external permission system (meaning remote, not in OpenACS) to the generic way of permissions in OpenACS so I do not have to touch every part of OpenACS to get those external permissions working and do not have to query the external permissions on every page but can "cache" them in the OpenACS permission system.

15: Re: Permission system in needs of revisit? (response to 14)

Posted by Tom Jackson on 09/08/07 08:32 PM

But what should I do with create? Here I need the proxy object, because I cannot give create permissions on a not yet created object. We could argue to say that "if you have create permissions on the context_id then you are allowed to create the object". But is this right? And wouldn't I still have to check if I am allowed to have write permission on the object_type?

With a role, you don't give role permissions to the individual objects, just the object type, so there is nothing different with create (in query-writer this is the 'new' operation). But another point to keep in mind with roles is that the not only filter the base objects, but the role can span multiple object types.

Otherwise, in order to allow users to serve in a role, you would have to assign multiple permissions. This could get confusing as roles may overlap, and if you remove a user from a role, you might damage the other role configuration.

Here I'm just speaking in general about a role and how it differs from objects and permissions on objects. In other words, think of roles as something layered on top of the main objects of interest. It is a description of what you can do, and a container for allowing users to assume a particular role.

In query-writer, I have one default admin group. It doesn't require any extra permissions, the user has to belong to the admin rel_segment (for the site). Even then, you could use a separate admin rel_segment to create a less expansive admin role. What I have found works best is for each package to configure their own roles which don't extend beyond the objects in that package, however, these could include objects which were initially created by another package. So for a particular package, the role assignment happens once for each user (for each role they can assume). For most applications, you don't even need to do this, the defaults work for an admin and regular user of the package.