[z3-five] Re: Security and Five

[Martijn Faassen]

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
> 
>>> As far as security is concerned, I think we are good enough to
>>> go. There are more features on zope2 security, like setDefaultAccess
>>> and declareObjectProtected, but I think we shouldn't go there. Most
>>> people don't even know those exist, and they don't have counterparts
>>> in z3. Even declarePrivate doesn't have a counterpart in z3. *wink*
>>
>>
>> We should make sure that everything that we *don't* explicitly set in 
>> ZCML is actually forbidden. I don't know what Zope 3 does if you 
>> supply a page and don't set a permission; the permission attribute is 
>> not required. I imagine it falls back to some default permission in 
>> that case.
> 
> 
> Nope, it doesn't. We just discovered a "bug" in the metadirective 
> interfaces. 'permission' *is* required on all browser:page[s] 
> directives, probably also for zope:view and browser:view. I will fix 
> this in Zope3 tonight.

So what will the fix entail? Making it required?

>>> I would suggest to
>>> move some files around, to make the package a bit more consistent. (eg:
>>> fiveconfigure.py to handlers/five.py, fivedirectives to
>>> directives/five.py, and so on)
>>
>>
>> It was consistent until you started to introduce the subpackages. :) 
>> Zope 3 doesn't define sub packages to separate out this code; modules 
>> are good enough there. So, I'll turn the question around on you. :) 
>> Why do you think it should be different for Five?
> 
> 
> I agree;

Okay, so unless Sidnei comes up with a great argument soon I'll move 
them. :)

> also, we might want to get rid of metadirectives.py and import 
> from zope.app.component etc. directly. I think having well-defined and 
> limited dependencies to zope.app packages is not only ok but preferrabl 
> since we don't want to reimplement everything ourselves, especially not 
> interfaces!

Agreed, we need to catalog what can be reused from Zope 3. Not 
everything easily code before, as I was kicking out some security 
related stuff. Since we're now implementing this at least in part, 
matters might change.

> Now that I've discovered the bug in Zope3, i think it would be even more 
> important to rely on Z3. Otherwise I'd now have to fix the bug in Five 
> as well. Would anyone object using imports from zope.app....?

We're already doing so to support ZPT, so no objections to doing that 
more. We will need a process to keep track on what exactly we depend, 
but for now we depend on all of Z3 anyway (at least what's released), 
which is simplest. :)

>> I was happy to see Philipp define a bunch of permissions. On the 
>> naming of the permissions, I think we should not use 'zope' but 
>> 'zope2' as a prefix in Five, as this makes it easy to avoid accidental 
>> name clashes with permissions that are truly Zope 3 native. This is 
>> important when porting code back and forth; something needs to change 
>> anyway and it's good to make it not work 'accidentally'. Is there 
>> anything in the system now that depends on the prefix being zope 
>> instead of zope2?
> 
> I don't think so. I don't feel strongly about it the prefix, so 'zope2' 
> would be fine with me.

Okay, then I'll look into changing that, unless Sidnei has some comments 
there as he did the security implementation. Perhaps there's some 
dependency on zope.Public or somesuch that we're not yet aware of.

I'd also like to look into the (mis)use of the 'title' attribute to 
define the Zope 2 permission name. Do we want to continue this or come 
up with our own attribute itself? If so, what will happen to title?

Regards,

Martijn