R. David Murray wrote:
And the expedition was a qualified success. It turns out that getObject has one of those nasty unadorned try: except: structures in it. It was masking an authorization error. The auth error is occuring in urestrictedTraverse, and the last lines of my traceback are:
File /usr/local/zope/Zope230/lib/python/OFS/Traversable.py, line 190, in unrestr ictedTraverse (Object: ApplicationDefaultPermissions) Unauthorized: 0060175400
0060175400 is the ID of the first object returned by the catalog.
Any guesses why this is happening? I get the same result whether I'm anonymous or logged in as a manager.
Also, anyone want to guess why getObject uses try/except? I can't off the top of my head think of any reason it should be there.
This is 2.3.0, I suppose I should try the new beta just for kicks...
Yes, do try the new beta. If this is what I think it is, it is fixed in the latest 2.3, as I submitted the patch that fixed it :-) Are your objects traversed to through an object that does __bobo_traverse__ -- like a ZPatterns Specialist, for example? If so, that's your problem. It's a combination of ZClasses not having a __roles__ attribute, and some security context being lost when going through a __bobo_traverse__. The patch to ZCatalog brains makes it fall back on resolve_url, which works just fine. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net