Florent Guillaume wrote:
Ah, okay, I thought that's what you meant, but I hoped it wasn't.
The fact that you expect this to work is a bug in Zope's security
machinery, IMHO, but sadly only IMHO it appears.
Huh? That's fundamental to Zope's security model.
As I said, I appear to be the only person
Chris Withers [EMAIL PROTECTED] wrote:
A, B and C are folders nested in each other i.e. A/B/C. A user does not
have access to A and B but he does have access to C. If getObject uses
restrictedTraverse it returns None immediately when traversing A, even
though the user is allowed to access
Roché Compaan wrote:
I don't get why you're not getting it :-)
A, B and C are folders nested in each other i.e. A/B/C. A user does not
have access to A and B but he does have access to C. If getObject uses
restrictedTraverse it returns None immediately when traversing A, even
though the user is
Roché Compaan wrote:
This is what I am arguing but I haven't had anybody agree/disagree with
me yet. It is also a lot simpler to fix:
return self.aq_parent.restrictedTraverse(self.getPath(), None)
---
return self.aq_parent.unrestrictedTraverse(self.getPath(), None)
I don't really mind
Max M wrote at 2005-3-11 19:10 +0100:
...
A single method might be public, but the rest of the object is hidden.
What to do then? Just ignore the public method and use the objects
overall visibility?
The object has a ObjectPermission that controls handling references (!)
to the object (itself)
Florent Guillaume wrote:
In the current getObject problem that concerns us, we want to do better
that restrictedTraverse,
Why? As far as any problems I had go, it was purely the returning None
when the user can see the object that was the bug. Provided getObject
raises unauthorised when a user
On Fri, 2005-03-11 at 15:47 +, Chris Withers wrote:
Florent Guillaume wrote:
In the current getObject problem that concerns us, we want to do better
that restrictedTraverse,
Why? As far as any problems I had go, it was purely the returning None
when the user can see the object that
Roché Compaan wrote:
The rest of the discussion basically boils down to figure out if the
user is allowed to access C or not.
Hasn't it been raised allready that there is no way of knowing that?
A single method might be public, but the rest of the object is hidden.
What to do then? Just ignore the
On Fri, 2005-03-11 at 19:10 +0100, Max M wrote:
Roché Compaan wrote:
The rest of the discussion basically boils down to figure out if the
user is allowed to access C or not.
Hasn't it been raised allready that there is no way of knowing that?
A single method might be public, but the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florent Guillaume wrote:
| Dieter Maurer [EMAIL PROTECTED] wrote:
|
|Roché Compaan wrote at 2005-2-25 17:22 +0200:
|
| Last year in March the following checkin was made that changed
| ZCatalog's getObject to use restrictedTraverse instead of
|
I implemented a publisherTraverse function like this FWIW:
def publisherTraverse(context, path):
# this is a hack to get around the fact that restrictedTraverse,
# unlike publisher traversal, does checks at every step of the
# path. We don't want to limit access in this way (e.g.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
| I implemented a publisherTraverse function like this FWIW:
|
| def publisherTraverse(context, path):
| # this is a hack to get around the fact that restrictedTraverse,
| # unlike publisher traversal, does checks at
On Thu, 2005-03-10 at 12:13 -0500, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
| I implemented a publisherTraverse function like this FWIW:
|
| def publisherTraverse(context, path):
| # this is a hack to get around the fact that
Roché Compaan wrote:
I'm unsure about the security check in the patch below - I copied the
way restrictedTraverse does it. I read through validate in the default
security policy but it is one of those methods where all the security
implications doesn't fit in your head all at once.
---
On Thu, 2005-03-03 at 09:27 +0100, Max M wrote:
Roché Compaan wrote:
I'm unsure about the security check in the patch below - I copied the
way restrictedTraverse does it. I read through validate in the default
security policy but it is one of those methods where all the security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jung wrote:
|
|
| --On Freitag, 25. Februar 2005 20:21 Uhr +0100 Dieter Maurer
| [EMAIL PROTECTED] wrote:
|
| Roché Compaan wrote at 2005-2-25 17:22 +0200:
|
| Last year in March the following checkin was made that changed
| ZCatalog's
16 matches
Mail list logo
