Re: [Zope-dev] restrictedTraverse doesn't give the good container.
Please don't cross-post. You already posted this exact question to [EMAIL PROTECTED], and received two replies to which you did not follow up. On Fri, Feb 13, 2004 at 12:56:13PM +0100, Pascal Samuzeau wrote: (snip) > I have no time to have a look on this, but anyone have seen this > problem and resolved it? Why should we have time to fix your problem when you apparently don't have time to respond to our replies? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PICO-SLIPPERY EATER! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] restrictedTraverse
Thanks, your points about "Access contents information" vs "View" enlightened me enough to fix my problems. Florent Stuart Bishop <[EMAIL PROTECTED]> wrote: > > On Sunday, May 12, 2002, at 01:27 AM, Florent Guillaume wrote: > > > With an object path /A/B/C where C has a local role allowing a user to > > view C but where B disallows acquisition of the View permission, the > > publisher correctly allows the user to see C. > > > > However restrictedTraverse('/A/B/C') fails ("You are not allowed to > > access B in this context"). This is because restrictedTraverse checks > > the security (using "validate") at *every* step, and obviously the > > user is not allowed to see B. Is there a reason for this ? Why not > > simply validate only at the last step ? > > Note that it doesn't check for the View permission though - it > checks for the 'Access contents information' permission. If this > fails, it fails because the site manager has explicitly said > that a group of users is not allowed to access any objects below > this point. -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] restrictedTraverse
On Sunday, May 12, 2002, at 01:27 AM, Florent Guillaume wrote: > With an object path /A/B/C where C has a local role allowing a user to > view C but where B disallows acquisition of the View permission, the > publisher correctly allows the user to see C. > > However restrictedTraverse('/A/B/C') fails ("You are not allowed to > access B in this context"). This is because restrictedTraverse checks > the security (using "validate") at *every* step, and obviously the > user is not allowed to see B. Is there a reason for this ? Why not > simply validate only at the last step ? Note that it doesn't check for the View permission though - it checks for the 'Access contents information' permission. If this fails, it fails because the site manager has explicitly said that a group of users is not allowed to access any objects below this point. If restrictedTraverse did not behave live this, a site manager would need to check the permissions on every single object in a subtree if they needed to restrict access to it, as well as every single object created in that subtree in the future. The current behaviour means that someone with 'Manage permissions' cannot make an object world viewable if it is in an area that the site manager has designated as restricted. It means that an object can be created in a restricted area and it stays restricted, even if it defaults to world viewable (such as an object that defines __allow_access_to_unprotected_subobjects__=1, or objects dynamically created from external sources like the file system or an RDBMS). > I have the need to programatically access object protected in such a > way. The workaround I'm going to use in my code for now is to call > unrestrictedTraverse and validate() by hand the resulting object. But > I'm concerned that there may be a more profound security reason I'm > missing. You may end up exposing an object that was never meant to be exposed to the user, as previously it was relying on permissions set in a parent container? You may be better off by granting the 'Access contents information' on B or allowing it to be aquired. -- Stuart Bishop <[EMAIL PROTECTED]> http://shangri-la.dropbear.id.au/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] restrictedTraverse
Anybody has any light to shed on this ? Especially the second paragraph... Thanks, Florent Florent Guillaume <[EMAIL PROTECTED]> wrote: > With an object path /A/B/C where C has a local role allowing a user to > view C but where B disallows acquisition of the View permission, the > publisher correctly allows the user to see C. > > However restrictedTraverse('/A/B/C') fails ("You are not allowed to > access B in this context"). This is because restrictedTraverse checks > the security (using "validate") at *every* step, and obviously the > user is not allowed to see B. Is there a reason for this ? Why not > simply validate only at the last step ? > > I have the need to programatically access object protected in such a > way. The workaround I'm going to use in my code for now is to call > unrestrictedTraverse and validate() by hand the resulting object. But > I'm concerned that there may be a more profound security reason I'm > missing. -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )