[Zope-dev] restrictedTraverse doesn't give the good container.
Hi, Today, I have this situation: Under my root Zope Site, I have this hierachy: - FolderA ---FolderB FolderC -FolderC What is interesting is that a folder named FolderC appears under another folder named with the same name. Assuming the path is the good one (path=.../.../FolderB) I try : herenow = context.restrictedTraverse(path+'/FolderC') - OK herenow = herenow.restrictedTraverse(path+'/FolderC') - OK Now I just delete the last FolderC, I have: - FolderA ---FolderB FolderC I try : herenow = context.restrictedTraverse(path+'/FolderC') - OK herenow = herenow.restrictedTraverse(path+'/FolderC') - OK BUT here I'm just not where I think to be, just because of the acquisition !!! I have no time to have a look on this, but anyone have seen this problem and resolved it? Sincerily PS -- Oreka ! Nous sommes l'internet moins cher ! Surfez 25% moins cher avec http://www.oreka.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 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
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 )
[Zope-dev] restrictedTraverse
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
--
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 )
