* vio <vmilitaru@sympatico.ca> [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
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
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 <steve@cat-box.net> [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
At 10:43 AM 1/19/02 -0500, vio wrote:
* vio <vmilitaru@sympatico.ca> [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.
* Phillip J. Eby <pje@telecommunity.com> [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
participants (3)
-
Phillip J. Eby -
Steve Alexander -
vio