[Zope3-dev] a note on groups and roles

[Chris McDonough]

> I think that only the part of the user folder implementation
> that does the mapping has to be placeful.

How would you decide who gets to perfom the mapping in a place?

> Yes, but that's exactly the type of tests that don't work properly in Zope
> 2. They DO work if I directly access a resource via an URL, because then
> the AUTHENTICATED_USER is identical with the user that is the nearest
> authentication source for the object. But if I test it from somewhere else
> as is the case with Kontentor's management interface, this doesn't work
> properly. The AUTHENTICATED_USER is the one that is used for
> authenticating the first object that is called (e.g. if I have
> http://server/folder/index_html, it will give me the user object that is
> in folder), but if I display another object on the page that resides in
> the parent folder, that one is NOT checked against its own nearest user
> folder instead, but against the same user object again.

Ugh.  I'm not sure I want to understand this problem. ;-)  At least in the
context of Zope 3 (if you can replicate the problem for Zope 2, please
submit a collector issue).

That said, in my suggestion for Zope 3, users may not have the same
username; a user with a particular username can be defined in one and only
one place.  The system would always authenticate you as the same user
regardless of the place in the system that you're accessing, presuming that
your user is defined at or below the place you're accessing.  This would
seem to make the sort of problem that you're talking about impossible.

> If local roles worked as advertised, that would be no real problem.
> But they didn't the last time we tried ...

"As advertised" is the problem there.  It's pretty hard to find people who
really know how anything is *supposed* to behave in the current
implementation.  Figuring out whether something is a bug or a feature in the
current security implementation takes a lot longer than it should.

> To wrap it all up: I think that the concept you describe will do what we
> need. But it is essential to make sure that there is a distinction between
> user source objects (which one could just call users or principal) and the
> places where they are mapped to permissions. The users can be a located at
> the root level or be completely placeless, but the mappings have to be
> bound to a place.

I think I almost agree except for the delegation problem I asked about
above.