[Zope] Where to authenticate during traversal

[Chris Withers]

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