Re: [Zope-dev] im_self of methods accessed via non trivial acquisition
At 01:12 PM 1/18/02 +0100, Stefan Bund wrote: Phillip J. Eby [EMAIL PROTECTED] writes: Method rebinding is done only when an item is retrieved from the aq_self side, and only if im_self points to aq_self. If these conditions are met, a new binding is created which points to the acquisition wrapper. This is a feature, not a bug. If you rebind im_self on the aq_parent side, and your method assigns a value to an attribute of self, it will be assigned to the wrong object! It is safe in your example to bind m.im_self to B, because B.aq_base is f, the true self of m. But it is not safe to bind m.im_self to A, because A.aq_base is g -- another object altogether. I guess another way to look at it is that a method retrieved from an acquisition-wrapped object will always meet the condition that method.im_self.aq_base is the original object the method was retrieved from. This ensures that the method simply works with an acquisition-wrapped version of its original self. Of course, im_self cannot be A, that would be wrong, but as far as I understand, it could be a *new* acquisition wrapper, something like /B o A/ or even /[f] o A/: C--A--O--[a] | | | | | [b] | | | O--B--O--[c] | | | | | | | [d] | | | | | O--[e] | | | | | [f] | | | [g] | B--O--[c] | | | [d] | O--[e] | [f] (that's what I refer to in the definition of /C/). So if /C/ is one of the aforementioned new wrappers, /C.aq_base/ is indeed [f] and therefore, /C/ would be safe as im_self? Hmm. Is there another reasun, why method rebinding works the way it does (returning a subtree and not a new acquisitionwrapper like described above) or am I completely amiss? Beats me. I guess nobody's asked for the feature, and in any event it requires global knowledge of the tree structure that would be very difficult to code. The current behavior is a rule that is applied locally at each acquisition wrapper, and the wrappers don't know what wrapper is pointing to them, so it's really not practical for them to try and do something that smart. It may also be that what you're asking for is a bad idea, in which case Jim Fulton can probably explain why. :) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
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 [EMAIL PROTECTED] [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 [EMAIL PROTECTED] and [EMAIL PROTECTED] Post to one or the other. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
vio wrote: 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? That would be a fine idea. Unfortunately, there is no straightforward way telling that you called methods on the security object in the class definition. When you call Globals.InitializeClass(your_class), it looks for a ClassSecurityInfo object, and doesn't find one. The fact that your class definition had the side-effect of altering the module's security object doesn't leave any traces in the class object that results from your definition. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
* vio [EMAIL PROTECTED] [020119 09:56]: vio wrote: 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? That would be a fine idea. Unfortunately, there is no straightforward way telling that you called methods on the security object in the class definition. Why not simply check for the keyword 'security.' in the class source ? Anything beginning with that word most probably has something to do with security. But if 'security' is not a reference to a security object, just throw an exception. This would make everything so much simpler. When you call Globals.InitializeClass(your_class), it looks for a ClassSecurityInfo object, and doesn't find one. If I understood correctly, this should be treated like an error: not allow the programmer to have calls to security methods which aren't there, because that's more or less what's happening here. And definitely not be silent about it !!! That's a syntax error or something. So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). I wonder what was carried at the class level, but something definitely was, else Python would have thrown something ugly at me. In my opinion, Globals.InitializeClass() should check such calls to security methods, and by all means NOT remain silent if it can not carry out the call because it couldn't find a ClassSecurityInfo object's method. Throw a 'method not found' error or something like that. Silence = 'bad'. I'll even say it's a bug. Vio ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
vio wrote: deletia So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). deletia In my opinion, Globals.InitializeClass() should check such calls to security methods You appear not to understand how Python and the declarative security system in Zope work. Globals.InitializeClass() does not read the source to your modules. You would need some sort of lint tool to perform the checking you describe. Why not try to implement a simple case of the error-correcting system that you describe? You might want to extend an existing lint tool such as PyChecker, to take account of conventions used in Zope products. http://pychecker.sourceforge.net/ -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
You are right, I struggled a lot to understand Zope's declarative security model. And I am still learning, so practice makes better. I didn't read Globals.InitializeClass() source, and I wrote my following comments out of the blue. Developping an error-correcting system might still be a little out of my league, for now. Anyway, the important thing is that your initial comments regarding Boring.py were right on target: 'security = ClassSecurityInfo()' must be declared INSIDE the class. It really solved my problem. Thanks again !!! Cheers, Vio * Steve Alexander [EMAIL PROTECTED] [020119 11:05]: vio wrote: deletia So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). deletia In my opinion, Globals.InitializeClass() should check such calls to security methods You appear not to understand how Python and the declarative security system in Zope work. Globals.InitializeClass() does not read the source to your modules. You would need some sort of lint tool to perform the checking you describe. Why not try to implement a simple case of the error-correcting system that you describe? You might want to extend an existing lint tool such as PyChecker, to take account of conventions used in Zope products. http://pychecker.sourceforge.net/ -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
At 10:43 AM 1/19/02 -0500, vio wrote: * vio [EMAIL PROTECTED] [020119 09:56]: So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). I wonder what was carried at the class level, but something definitely was, else Python would have thrown something ugly at me. Check the Python reference manual -- not the library reference, but the language definition. You'll find that Python has two primary scopes: local and global. When a class statement is executing, the local namespace is the future __dict__ of the class, and the global namespace is the module __dict__. If security.Foo() is in the body of a class, and security is not in the *local* namespace (i.e. already defined in the class body), then it will be looked up in the global namespace. Thus, your calls went to the module-level security, but no security object was present in the resulting class (because there was no statement placing one there). IMHO, you don't want to share a security object between more than one class, since presumably they will have different declarations and thus each require their own. So there's no reason to create a ClassSecurityInfo object at the module level, anyway. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
* Phillip J. Eby [EMAIL PROTECTED] [020119 12:04]: ... IMHO, you don't want to share a security object between more than one class, since presumably they will have different declarations and thus each require their own. So there's no reason to create a ClassSecurityInfo object at the module level, anyway. Good point. Actually, I only declared ClassSecurityInfo object at the module level out of convenience: I thought each class (presuming there were more than one in the module) could reference that same security object, so maybe save a few CPU cycles in the process (plus, I saw this done in some product I used as a learning example). But your point is well taken ... plus module-level security declarations have no effect at the class level. Vio ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
