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





_______________________________________________
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 )

Reply via email to