[z3-five] Re: Security and Five

[Philipp von Weitershausen]

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 :)))

> I am also likely going to get rid of the new subpackages you added just 
> to handle the content directive and merge them into the main modules.
> Next time we introducing changes that introduce new packages like that, 
> especially if there is already a different way, we should have some 
> discussion on the list first, or alternatively check in as a branch and 
> then bring it up (that's also good if tests are still lacking).

+1

We should soon open a bug tracker (I'll do that) 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).

- 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.

>> I've checked in the work i've been doing on security decls in
>> zcml. However, I've tried to use the five:content directive to protect
>> views,
> 
> Which in my opinion is a definite misapplication of the five:content 
> directive anyway; it should be applied to content. That said, it's nice 
> to be able to do five:content on actual content classes now -- I hadn't 
> imagined we'd be at that stage already.

I agree 100%.

>> and found out that it doesn't quite work because when the page
>> directive is used, a metaclass is created, and the security decls
>> didnt took effect yet because they are processed later.
>>
>> It seems to me that the right way to handle this is to have a
>> <require> and <allow> subdirectives to the <five:page> directive
>> instead. I don't remember from the top of my head how security in
>> views is handled.
> 
> Whenever in doubt, study Zope 3. :)
> 
> the code is hiding out in zope.app.publisher.browser, much of it in 
> viewcode.py. This time though it bounces us back to zope.app.component, 
> as IBasicViewInformation is defined there, which is used by IPage.
> 
> What it defines that is relevant is the following:
> 
>     permission = Permission(
>         title=u"Permission",
>         description=u"The permission needed to use the view.",
>         required=False
>         )
> 
> Permission is in my mind the most important one; the actual view is the 
> only thing on the view class that by default should be exposed to the 
> outside world. Everything else should be private.

+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?

> 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?

> 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.

> 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:?

Philipp