[z3-five] Re: Security and Five

[Martijn Faassen]

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
> 
>> Some procedural matters first:
>>
>> When I saw the first checkin, I was initially a somewhat shocked to 
>> see the 'content' directive used for protecting views; I see in recent 
>> checkins that has been amended; good, as it doesn't make much sense. :)
> 
> 
> Yes; we should mimic Zope3 as much as possible. I'm amazed by Sidnei's 
> work, though. We can now use get rid of ClassSecurityInfo everywhere, 
> basically :)))

Yes, that is definitely great, though with Five views (which are 
trusted) it's of somewhat limited utility unless the app for legacy 
reasons also depends on exposing methods directly. (they may be used 
from Python scripts, for instance)

[snip]
> We should soon open a bug tracker (I'll do that) 

A roundup instance on codespeak?

> and make a TODO list. 
> The following things are on my mind:
> 
> - Provide some standard interfaces for Zope2 stuff, such as
> 
>   * IObjectManager (provided by OFS.ObjectManager.ObjectManager)
> 
>   * IFolder (provided by OFS.Folder.Folder)
> 
>   * ...
> 
>   These interfaces would live in a subpackage (I propose) which could
>   perfectly be optional to Five, but I think it'd be useful (e.g. for
>   getting adapters from IObjectManager to IContainer maybe).

If it's optional then I think it could also make sense as an extension 
(another product). The question here is what is our main priority; Zope 
2 users are used to installing extra products, while in Zope 3 you'd 
plug in extra ZCML. Doing it on a product basis gets us in product 
ordering issues, which ZCML gets executed first? I think on the longer 
term we need the product approach anyway to make the Zope 2 experience 
'right', and I have some ideas on how to tackle the ordering issue.

> - implement five:addMenuItem directive (or similarly named) which takes 
> care of registering a meta type with the "Add ..." drop down box in the 
> ZMI. In classic Zope2, we used to do this in __init__.py, e.g from the 
> FiveViewsDemo:
> 
> def initialize(context):
>     zcml.process('configure.zcml', package=Products.FiveViewsDemo)
> 
>     context.registerClass(
>         simplecontent.SimpleContent,
>         constructors = (simplecontent.manage_addSimpleContentForm,
>                         simplecontent.manage_addSimpleContent),
>         )
> 
> I would like that 2nd statement to be in ZCML as well. Then we'd just 
> need a boilerplate initialize(context) function in all Five products. 
> And even that could be imported from Five if we make it general enough.

That'd be really neat! Of course then we need to do something 
interesting for add views to take care of 
simplecontent.manage_addSimpleContentForm, and things like icons, etc..

[snip]

> 
> 
> +1
> 
>> Since in Zope 2 we don't have Zope 3's security model, attribute and 
>> template views run in trusted mode. It is very important to protect 
>> them right on the outside, but protecting anything else that doesn't 
>> get called by the web doesn't have any effect anyway. In which case, 
>> why bother? :)
> 
> 
> How can you be so sure that it doesn't get called?

Well, I mean, it needs to be protected, but set to private. I doubt we 
need anything else for views. For content we do, especially since we 
have legacy code like Python scripts around that want to call methods on 
contents directly (not using the view system). We have five:content to 
take care of that.

>> Following that line of argument, the following two also defined on 
>> IBasicViewInformation aren't very useful and we should ignore them for 
>> now:
>>
>>     allowed_interface = Tokens(
> 
> ...
> 
>>     allowed_attributes = Tokens(
> 
> ...
> 
>>
>> These only make sense for things that are indirectly called by either 
>> attribute or template-based page. This isn't going to happen anyway. 
>> This also explains why doing permission definition using five:content 
>> on content classes is of only limited utility, as views on that 
>> content, being trusted code, will break right through that anwyay.
> 
> I'm not following you here. Why would it be such a problem to support 
> the above parameters? Why wouldn't it make sense?

Because the attribute or template that calls these methods is trusted 
code. Use from pages is the only use case for these methods; nobody else 
is going to call them. Trusted code in Zope 2 is going to ignore Zope 2 
security anyway.

>> So, the right way to go ahead is simple: just add the permission 
>> attribute back to IPage and make it work.
> 
> 
> Yes :)
> 
>> It may be easiest to the permission attribute work by doing an 
>> explicit check in Viewable.__bobo_traverse__. This would allow us to 
>> store the permission on the view in a different way than Zope 2's 
>> system mandates, and we could forgo messing around with classes.
> 
> 
> -1. Zope2 should handle the permissions. That makes it more predictable 
> (I know, that can be interpreted as a joke) and more compatible with 
> products like VerboseSecurity.

Well, Zope 2 can only handle the permissions at the 'outside' anyway; 
permissions only make sense on views from the Five perspective.

>> The five: ZCML namespace shouldn't diverge from Zope 3's. Sometimes we 
>> may feel we want to create a new directive altogether, but all 
>> directives derived from Zope 3 should follow Zope 3 strictly. The only 
>> thing we can do to alter the schema is to do a subset instead, 
>> dropping some fields we cannot support.
> 
> 
> Well, we're currently mixing in the zope: and the browser: namespace in 
> five:. Maybe we should create a five-browser:?

Actually for the 'content' directive I don't think we need a different 
namespace at all; we can just use the same one as in Zope 3 as we're not 
changing anything. I had the five namespace originally for things that 
*didn't* quite work like Zope 3, but since the page directive is 
starting to look very much like Zope 3's now, it might make sense to 
move it into the browser namespace altogether.

Regards,

Martijn