Just a word to thank you for your reply. But incidently, wouldn't it be a good idea for Globals.InitializeClass() to throw an error or a warning of some kind for hanging 'security.stuff()' declarations, declarations which do not have a related ClassSecurityInfo object AT THE CLASS LEVEL? To the unaware beginner (like myself) this creates a very obscure bug: the declaration at the module level 'hiding' the missing ClassSecurityInfo object (at the class level). I see some other discussions on this list on this topic, so maybe this problem is already being addressed. Anyway, I would never have found this alone by a long shot. Thanks. Sorry for the cross-post. * Steve Alexander <steve@cat-box.net> [020118 15:43]:
vio wrote:
Could someone have a look at the following 'Boring' class with the security functionality added (as described in ZopeBook/6.Security and some other products). Could 'security' machinery be broken in Zope-2.4.1 ? It surely doesn't seem to work as adverised, on my machine at least (Debian Linux 2.2, Zope 2.4.1 (source release) python 2.1.0, linux2). Tell me if it works on your installation.
Boring.py -------------------------------- __doc__ = "" __version__ = '0.1' import Globals from Globals import HTMLFile # fakes a method from a DTML file from Globals import MessageDialog # provid from Globals import Persistent # makes an object stick in the ZODB import OFS.SimpleItem import Acquisition import AccessControl.Role from AccessControl import ClassSecurityInfo
READ_PERM = 'View Stuff' WRITE_PERM = 'Change Stuff' security = ClassSecurityInfo()
You have declared your ClassSecurityInfo object at the module level, rather than as an attribute of the class you wish to make security statements about.
Please do not cross-post to both zope@zope.org and zope-dev@zope.org. Post to one or the other.
-- Steve Alexander