Chris Withers wrote at 2005-2-18 11:49 +0000:
...
ZPublisher cannot use "restrictedTraverse" because authentication happens only at the end of traversal.
Up to this point, there is no user and "restrictedTraverse" is likely to fail.
Okay, but maybe this should change? I know it's caused you problems in the past and resulted in having to implement a post-traversal hook/hack...
When you change it, you will loose user folders in subsites (which are quite essential). When you keep user folders in subsites, then you first must determine the subsite (without security checks) before you can determine the user. Of course, it would be possible to later check that the user determined after traversal had in fact the right to access any object accessed in between. You could do this in a post-traversal hook/hack ;-) In case, you would really care...
There's still one remaining question:
What role-to-permissions mappings do you set so that no-one can access a particular object's contents, once they know its id?
In general, this is a very difficult questions. * The concrete permission depends on the object type. It is the permission that is defined with "declareObjectProtected(...)". Usually it is "Access contents information", but templates use "View" instead and other objects may choose to use a different permission. * Even when the "object permission" is not granted, special methods (protected by whatever permission) may still be able to access an object's content. Thus, you would need to revoke grants to such permissions as well. -- Dieter