[z3-five] Security and Five

[Martijn Faassen]

Sidnei da Silva wrote:
> On Mon, Jun 21, 2004 at 10:51:25AM +0200, Martijn Faassen wrote:

> Thats fine. I didn't knew of any policy about it so I've fallback to
>  the 'collective' policy -- get things done first, worry about beauty
>  later :)

I think in the Zope 3 Base we're closer to the Zope 3 policy than the
collective policy, though we'll probably focus a bit more about
immediate pragmatic payoff.

>> Anyway, I'll try to do a more comprehensive review of it all today
>> and refactor some of the code where I think it's necessary. I'll 
>> also try to devise some more tests. :)
> 
> Feel free to do so!

Right now the security tests didn't work for me, so I will have to
repair them first. :)

[permission attribute]

> That's what I did. At first I thought your views were different, but
>  then I realized they were pretty much the same as z3 and used the 
> same approach.

They actually used to be different, but last week I've changed them to
be almost the same as Zope 3's.

[snip snip]
>> 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.
> 
> Yeah, thats true. For views it doesn't matter much (currently), but 
> for direct access to the object it does matter. Remember if a method
>  has a docstring, it can be called, and I think that by default the 
> permission is public!

Right, it is still a tremendously useful feature to define permissions
on content classes from ZCML. :)

[security declarations]
> I've tested it myself, and the current way is working almost 
> perfectly. Content methods are being protected the way its expected,
>  and view *methods* too. views using *templates* are not being 
> protected the right way for some reason. If I try to check the 
> security for the 'index' attribute and its a ViewPageTemplateFile, it
>  raises Unauthorized.

Okay, we'll have to resolve that one though, as it's right now possible
to protect templates in any way, which makes them rather dangerous to
use. :)

[snip]
> Yes. I've added the <deny> for declarePrivate, but I hope thats fine.
>  I was thinking of adding a couple others like setDefaultAccess() and
>  declareObjectProtected(permission). How do you feel about it?

Hm, I was wondering whether that came from, as it's not in Zope 3. I'm a
bit wary of adding new knobs to directives that are in effect the same
as in Zope 3. I've in fact moved to try to use as much of the Zope 3
interface declarations at possible, though the 'Permission' field seems
to be a blocker here still..

Perhaps we should come up with a new five: directive that can do the
deny and other stuff. It should hopefully be not necessary to use it;
perhaps we can make the content directive have a declareObjectPrivate or
somesuch always..

Regards,

Martijn