Dieter Maurer wrote:
- the getObject method never tries to catch any exceptions, it just uses a simple restrictedTraverse to turn the path stored in the ZCatalog into an object
Sad that the long discussion could not convince you that "restrictedTraverse" is not the correct approach...
Sad that you didn't read some of the long discussions ;-) This was agreed to be one of two "correct" approaches depending on your point of view. In fact, both Zope 2.7.7 and 2.8.0 support this approach, and in 2.8.0, it is the default. There are two reasons why SaneBrains is relevant for Zope 2.8.0, one minor, one major: - the minor one is that the code in 2.8.0 supports both approaches, and so is more complex, and hence slightly slower than the one SaneBrains uses - the major one is that SaneBrains' getObject does a pure restrictedTraverse rather than 2.8.0's unrestrictedTraverse-to-parent-followed-by-restricted-traverse-to-actual-object. There are two views to how authentication should work: 1. Traversal should be unauthenticated and allowed to all and the nsecurity performed on the object at the end of the traversal. 2. Traversal should always be with an authenticated user and access control applied at each step in the chain. ZPublisher does the first, restrictedTraverse does the second. ZCatalog is left stranded in the middle and so we have the current vague simulation of what ZPublisher does. Now, people have made good arguments about why ZPublisher does 1, but I can't remember them other than remembering they were valid, but rarely applied in my case. I really wish there was an option to make ZPublisher do 2, but there isn't and I don't have the foo or the time to make it a configurable option, as it should be. However, SaneBrains does at least make 2 possible for ZCatalog searches and their results, which is as good as I can hope for for now. It turned out to be crucial in a recent Plone-based project as it highlighted ZPublisher inadvertently making certain objects anonymously accessible: Imagine documents that can have attachments. Attachments have a single-state workflow which has them always accessible with their access being controlled by the workflow state of their containing document. Sounds good, yes? Well, what we were experiencing is that documents were showing up in portal_catalog searches but then causing the results page to blow up with "None has no attribute 'absolute_url'" errors thanks to Zope 2.7.5's getObject implementation. After inserting SaneBrains, it turned otu to be unauthorised errors. "Hmmm..." we thought, "why are unaccessible objects showing up in our search results when portal_catalog is supposed to filter for those kinds of things?" The answer, of course, is that the attachment itself was anonymously viewable, but it was in a document that was 'private', so portal_catalog's filtering was letting it through, but the call to getObject was bombing out when it tried to traverse through the containing document. "Ok.." we thought, and caught the Unauthorized errors now being raised by SaneBrains and stripped those items out of the search results. ...but wait, there's more: Thinking this through, once someone knows the URL of an attachment, and the are often emailed around with this project, they will always be able to download it, regardless of the workflow state. "Eeep :-(" we though, and cursed and swore a lot at ZPublisher before moving attachments to a two-state workflow: public and private, which solved both the portal_catalog-not-filtering and the ZPublisher-not-requiring-authentication problems with the attachments in question. Morals of the story: - SaneBrains is a GOOD idea, even if only for debugging purposes - ZPublisher doesn't always do what a lot of us would expect. Sadly, that's by design and won't change, even though it's not really documented in as big or bold letters as it should be. cheers, Chris :-P -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk