[Zope3-Users] questions on the security framework

[Sven Schomaker]

Hi Stephan,

thanks for your respond. Besides my posting on the dev-list,
which is about a more general questions on the present issue
I got some questions and remarks in special to your respond
here.

Stephan Richter wrote:

>On Thursday 30 December 2004 05:18, 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.
>>    
>>
>
>I think this particular scenario is still an open issue.Our standard response 
>until now was to simply assert the security on the adding views. If people 
>cannot create an object in the first place, they cannot add it to the folder 
>either. But this solution does not seem right for some reason (maybe it is 
>though).
>  
>
Well, in my mind restricting access to the view to prevent addition,
deletion or modification of data seems not to be a neat solution even
though it definitely works.

The problem I see is that in my opinion it seems generally questionable
to restrict access to the view and let the actual operation on the data
unsecured. A resourceful one might find a way to circumvent the view
and directly access the data. Even though this might be not much of
practical but more of philosophical concern, I don't feel too comfortable
with having an open backend while only securing the frontend (which is
the way I see it basically what you suppose). But, maybe this discussion
is more of a general kind. If so, we can savely skip it. Any thoughts?

>The better solution would be to make the message board not a container but 
>contain two attributes called `topics` and `announcements` which are folders. 
>Then you can control the access/mutation of each separately.
>
>  
>
Would this approach not yield to having to abandon the basic and
build in facilities (views) to add/remove items to the container
since one would have to perform custom calls on the respective
methods (at least I think it is so)?

>>Another question is about involving the workflow
>>into the security system. As I was able to determine
>>there is the possibility to configure permissions
>>to cause 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?
>>    
>>
>
>Security for an object is controlled via checkers. Checkers are registered for 
>a type of object. So clearly, if you do not change the type of object (which 
>would be one solution), you have to change the behavior of the security 
>mechanism. There you have two choices:
>
>1. Write your own Security Policy.
>
>2. Write a custom Checker class.
>
>While (1) is not as hard to do as it may sound, I do not know how to do that 
>well, so I am just going to outline option (2). Instead of just using the 
>common `InterfaceChecker` class (`zope.security.checker`), you write a 
>checker that looks at the provided interfaces to allow access to an attribute 
>given a particular permission. One thing the workflow can do is to provide 
>and unprovide interfaces using the `directlyProvides()` method from 
>`zope.interface`. You will have to implement your own security ZCML 
>directives, though, to make this work.
>
>  
>
Hmm, maybe I'm a bit of a sissy by trying to circumvent any touch of
the security framework but what about defining an extended set of
states and transitions to reflect the modification and access to the
content objects in a specific state. This would probably introduce
a (pretty artificial) state like modified and some state transitions like
submitted_modified, which are permitted or restricted statically to
distinct roles?

 From an architectural point of view this would probably be an misuse
of the workflow idea (Please forgive me about it as I'm already ashamed
to suggest such a thing at all). I'm even not sure if it would actually 
work.
Any suggestions/thoughts on it?

>>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 is no concept of an owner in Zope 3. 
>See http://dev.zope.org/Zope3/NoOwnershipRole
>
>  
>
Ok sounds plausible but need to think about it in more detail
in an calm moment - thanks.

>>And last but not least is there the concept of local
>>roles like it has been in z2?
>>    
>>
>
>Yes, there are local roles in Zope 3. This is also the way to implement the 
>Owner role. See the `zope.app.homefolder` code in the trunk for an example 
>how to set special permissions for a contetn object locally.
>  
>
Will have a look at it when concluded the permission thing above.

>Regards,
>Stephan
>  
>

Thanks + Regards

Sven

PS: Sorry, much text again;-)