[z3-five] Security and Five

[Martijn Faassen]

Sidnei da Silva wrote:
> On Sun, Jun 20, 2004 at 12:52:18PM -0300, Sidnei da Silva wrote:
> | 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.
> | 
> | If I am correct, doing security decls in python as it was done in
> | FiveViewsDemo before my changes didnt work either. Martijn, can u confirm?
> 
> Scratch that. The problem seemed to be that BrowserView didnt validate
> security against the __page_attribute__ method. I added the security
> check there and a 'permission' attribute to the five:page directive to
> protect the page. That was when I realized that a page is usually a
> single attribute of a view class.

Ah, I see you've already done stuff described in my last email. Great! :)

> | For content, the security decls in zcml should be working just fine as
> | there's no metaclass involved.
> 
> I changed FiveViewsDemo.simplecontent.SimpleContent to use
> five:content directive, and it seems to work like a charm. Yay!

Except that views can break right through this, right? This is something 
we cannot avoid in the Zope 2 security model anyway.

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

> Martijn, tell me what you think about it this far.

Overall, a lot of great progress has been made, thanks! I want to review 
it all carefully and perhaps add more tests next.

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

Regards,

Martijn