On Mon, Jun 06, 2005 at 05:50:42PM -0400, Paul Winkler wrote:
On Fri, Jun 03, 2005 at 04:58:57PM -0400, Paul Winkler wrote:
Just now I saw something that *may* be related, some imports that were fine on zope 2.7.3 are giving me trouble on 2.7.6, but this is a very preliminary observation and i have not had time to troubleshoot yet. Monday...
False alarm, I get the same problem in 2.7.3 and 2.7.0, most likely an error in my own code.
Maybe the following will be interesting, if not helpful, at some date in the future if somebody else experiences weird problems with ModuleSecurityInfo().declarePublic()... More info about the symptom: While importing (i.e. from a .zexp file) an entire CMF site, I was getting an Unauthorized error that I was not allowed to access the method (let's call it 'foo') in the current context. Now, foo.py is a script in one of my filesystem directory views, and is used both for a keyword index and metadata in my catalog tool. And yes, I verified that there is no other object by that name. foo.py is pretty darn simple: from Products.FooProduct import Utils return Utils.foo(context) And in Products/FooProduct/__init__.py, I had this: ModuleSecurityInfo('Products.FooProduct').declarePublic( 'blah', 'foo') The interesting thing is that all this works just fine in the normal operation of the CMF site. It *only* raises Unauthorized during an import of a .zexp of the CMF site. As if that wasn't weird enough, after a very long and tedious round of troubleshooting today, I discovered that two changes were sufficient to make the symptom go away: * Remove an (unused) import from FooProduct/__init__.py. (The imported object was a class, defined in the same Utils.py as the foo function. This import was vestigial.) * Completely remove another product (which does not import any code from FooProduct, nor vice versa.) Neither of these changes alone is sufficient - I have to do both. Once I do that, I can import the .zexp, then I can revert those code changes and restart zope and all is good. Neither one of those changes has anything whatsoever to do with foo.py AFAICT. Sounds bizarre, but this is 100% reproducible. This is some crazy voodoo. If I can boil it down to a reasonably small demonstration, I'll file a collector issue. But I don't think I will bother to, because it finally occurred to me that if I change the form of the import in the script, it works. i.e. if I change foo.py to look like this: from Products.FooProduct.Utils import foo return foo(context) ... then it works all the time, even during the import, regardless of the aforementioned voodoo changes. Weird, huh? Security sucks. -- Paul Winkler http://www.slinkp.com