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
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 eith
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 all
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 (i
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,
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 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 objec
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
Tres Seaver <[EMAIL PROTECTED]> wrote:
> 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
Chris McDonough wrote at 2005-3-10 11:28 -0500:
>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
># pat
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 res
-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 eve
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. ne
-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
|>
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
>
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.
--- CatalogBrain
-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 g
18 matches
Mail list logo
