[z3-five] Five 1.0.2 [was: Security bug in browser menus?]

[Philipp von Weitershausen]

Lennart Regebro wrote:
>>I think I have found a bug regarding menu items in Five. Basically,
>>unless the menu item isn't protected with zope.Public, it will never
>>show up. I can verify this in a test
> 
> I just checked and I can't reproduce this with Five 1.0.1.
> I'm using menus of course, and have done it for quite a while, but all
> has been unprotected (Zope2.public in fact) but last week I refactored
> the security machinery of the calendar, so now I can start using
> proper protection for pages and menues, and it works for me...

I actually found out that both us are right :).

Lennart is using CMFonFive which unfortunately does a lot of code 
duplication regarding menus. In particular, it duplicates the getMenu() 
function in which Five's checkPermission is called. That is why it's 
been working for Lennart in the past, even though Five's checkPermission 
and Zope 3's checkPermission behaved differently. (I couldn't figure out 
why actually the code duplication is necessary; if it is for the 
security, then it can now be gotten rid of...)

Now, when not using CMFonFive but regular Zope, I was able to actually 
reproduce the security problem. I have fixed it as indicated in previous 
emails on this thread: The Zope 3 interaction is actually a bridging 
object that bridges between Zope 3's checkPermission function and Five's 
checkPermission function.


Since this fix as well as yuppie's bridging fix also concern Five 1.0, I 
have backported them to the 1.0 branch. I would like to fire out a 1.0.2 
release tomorrow if nobody minds. I'll also handle the merging to the 
Zope 2.8 branch and the Zope 2 trunk.

Have a good night,

Philipp