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 )
