[Zope3-dev] questions concerning the security framework

[Garrett Smith]

Sven Schomaker wrote:
> Since the message board is a container and the
> framework uses __setitem__ to add new objects
> to the container, how would one distinguish the
> permissions to add an announcement from the
> permission to add a topic with zcml or with
> explicit python coding.

You can attach a precondition to your container's schema's __setitem__
method. (See zope.app.container.constraints.IItemTypePrecondition.)

In the precondition '__call__' method, you can use
zope.security.checkPermission to test whether the current user
(principal) has permission to access the object being added via
__setitem__. In the precondition 'factory' method, you can check
permission on the object factory (before it's created).

This approach has the benefit of filtering out object types the user
can't add from the default Add UI.
 
> Another question is about bringing the workflow
> into the security system. As I was able to determine
> there is the possibility to configure permissions
> on causing state transitions using zcml. Thats fine
> so far, but how would one restrict e.g. the ability
> to modify messages once they have been submitted,
> i.e. bind the permissions on content-objects to a
> specific workflow state?

I believe the way to handle this is to modify principal or role
permissions for the object whenever a workflow state changes. E.g. when
the state changes to 'Closed', you would remove the 'zope.ManageContent'
permission for the ordinary user role, but preserve it for managers.

I'm not familiar with the current state of workflow (I suppose pun
intended), but I think this is the approach one would take.

> The next question is whether there is something
> like a build in role for the owner of an object or
> if there is the notion of ownership at all? For me
> this seems to be necessary if one would only grant
> permissions to modify an object if he/she is the owner
> of that particular object as it has been done in z2.

There's no build-in notion of 'owner' in Zope3. One could implement such
a concept in their application using workflow rules. E.g. you might
assign a principal role of 'yourapp.Owner' for an object when it's first
created. Depending on your application, that role might be transferable
to another principal, or shared among more than one principal, etc.

> And last but not least is there the concept of local
> roles like it has been in z2?

I believe this is being handled (or will be handled) with the pluggable
authenticaion service (PAS). I'm not sure what the status of this is.

 -- Garrett