[Zope] Where to authenticate during traversal

[Dieter Maurer]

Chris Withers wrote at 2005-8-25 18:38 +0100:
>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 ;-)

I did and understood it ;-)

>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.

How do you explain that Zope 2.8.x does *NOT* use
a simple "restrictedTraverse"
(in "Products.ZCatalog.CatalogBrains.AbstractCatalogBrain.getObject")
but instead an "unrestrictedTraverse" to the parent followed
by a "restrictedTraverse" for the last step?

Using a "simple restrictedTraverse" is wrong!

> ...
>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.

And this is wrong -- but you apparently did not got this
from the discussion...

And that is what I am sad about (as I wrote)...

> ...
>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.

Long ago, ZCatalog used "unrestrictedTraverse" followed
by a "validateValue".

Then, it was changed to use "restrictedTraverse".
This was a bug. It resulted in lots of unexplained "None" returns
which should not have happen because the same users could
access these objects without problem (due to the way ZPublisher
works which has essential use cases).

The ZCatalog behaviour was fixed again in a late 2.7 release.
The long discussion was about this fix...

You are apparently proud to go back again...
This does not justify the attribute "sane" (rather "insane") ;-)

> ....
>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?

No: a single state workflow should not control permissions
(but allow them to be controlled by the environment).

>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.

That's one reason why the "restrictedTraverse" implementation
was replaced by the more complex "unrestrictedTraverse-to-parent then
restricted-to-final-object" one.

>"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.

Hopefully, you see the effect of the "simple restrictedTraverse"
and why the new implementation is better...

>"Ok.." we thought, and caught the Unauthorized errors now being raised 
>by SaneBrains and stripped those items out of the search results.

Drop the permission catch of your workflow, let permissions be controlled
by the environment. Then, the catalog will filter correctly -- without
the need to catch Unauthorized ;-)

>...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.

This, too disappears, once you get your workflow right...

...

-- 
Dieter