Re: [Zope] Where to authenticate during traversal
Chris Withers wrote at 2005-8-31 08:45 +0100: > ... >I notice you're still silent about my comments on whether Zope's >security policy as a whole needs an alternative ;-) I argued earlier against it. That's why I was silent this time... -- Dieter ___ 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 )
Re: [Zope] Where to authenticate during traversal
Dieter Maurer wrote: I forgot to mention that you need to reindex the index "allowedRolesAndUsers" for descendants when you change the permissions and descendants inherit them. Well, I know THAT ;-) (in fact, it's something I'm hoping to optimise some time soon...) I notice you're still silent about my comments on whether Zope's security policy as a whole needs an alternative ;-) Chris -- 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 )
Re: [Zope] Where to authenticate during traversal
Chris Withers wrote at 2005-8-29 22:21 +0100: > ... >> a single state workflow should not control permissions >> (but allow them to be controlled by the environment). > >Now THAT is a good point... I forgot to mention that you need to reindex the index "allowedRolesAndUsers" for descendants when you change the permissions and descendants inherit them. -- Dieter ___ 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 )
Re: [Zope] Where to authenticate during traversal
Dieter Maurer wrote: 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! No, it's a different and valid approach... 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)... ...no, I'm guessing YOU didn't get what I wrote below about alternative security policies ;-) 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... I don't catch any exceptions, and yes, I'm happy that it is the right decision... This does not justify the attribute "sane" (rather "insane") ;-) I'm not forcing you to install it... 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). Now THAT is a good point... That's one reason why the "restrictedTraverse" implementation was replaced by the more complex "unrestrictedTraverse-to-parent then restricted-to-final-object" one. ...and still would have resoluted in a None being returned in this case! Hopefully, you see the effect of the "simple restrictedTraverse" and why the new implementation is better... No, I see why Zope's security policy should have some different options... ...which I see you conveniently snipped off the end of the email. Oh well, it seems legitimate differences of opinion aren't acceptable to you, which is a shame ;-) Chris -- 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 )
Re: [Zope] Where to authenticate during traversal
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 ___ 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 )
[Zope] Where to authenticate during traversal
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 )