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
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
