[Zope] Aquisition, UserFolder and security

[bruno modulix]

Julien Anguenot wrote:
> bruno modulix wrote:
> 
>>>Julien Anguenot wrote:
>>>
>>>
(snip)
>>>>To sum up it's a matter of configuration.
>>>
>>>I'm afraid there's more to it than just a matter of configuration, cf
>>>below...
> 
> 
> I confirm. For having done the intranet of the Senegal gouvernement
> (almost 35 CPS  (one instance for each ministry) on the same Zope within
> a ZEO env linked on a central LDAP with differents branches for users
> and groups per ministry) using CPS, I have sort if an idea what you're
> trying todo here.
>
>>>
>>>I've spent quite some time investigating the
>>>CPSUserFolder/Metadirectories/Stackingdirectories/backingDirectories...
>>>solution, and the final word (from Olivier Grisel, cf the cps-users ml)
>>>was that some code concerning roles and groups management was not yet
>>>fully implemented, so the whole thing couldn't work without patching and
>>>merging parts of CPSDirectories - which was a definitive no-no for us.
> 
> 
> I assume, you're talking about roles and groups compute schema fields
> here on directories. This is TALES expression linking the directories.
> The code can be wherever you wanna, even within the TALES expression if
> you feel like...
> 
> That's probably, what Olivier tried to say. Still I didn't follow the
> discussion at this time.

Too bad :(

You'll find it on the cps-users list. I'm not a CPS expert[1] - and not
even a Zope expert - but from what I saw, it seemed to imply more than
only TALES expressions...

[1] given the change pace and resulting lack of  documentation, I guess
only you Nuxeo guys have a good understanding of the whole product...

> Let me add that CPSUserFolder works and is in production for a while now
> in several projects. So be sure it's stable.

I don't doubt it works fine. I just didn't managed to make the whole
thing work, and couldn't afford to spend more time on it.

>>>I don't know if this has been fixed in 3.3.6, but anyway, this part of
>>>our project is supposed to be already working (and mostly does, except
>>>for this security problem), and we can't afford to come back on it, as
>>>it would delay delivery by at least one week - which is also not an
>>>option. But thanks anyway...
>>> 
> 
> Then, you might have a design flaw...

Probably. Certainly. But we'll have to live with it for at least this
and next iteration - our customer needs a working solution for
yesterday, and we have pretty good reasons to do whatever we can to
deliver yesterday.

> You didn' reply to my question at the first place : are you controling
> the LDAP (rw) ?

Actually, no, r only. As I answered to Jens, it's part of a bigger
system, and we have very few freedom here. This will probably change in
the future, but we must first deal with the existing situation.

> Are the schemas describing your users differents in between the CPS
> instances ? 

Yes.

> etc...
> 
> CPSUserFolder has been designed to tackle such a use case. (Not only
> this use case but this one has been a reason of the existence of this
> product.)

I know, that's why my first try was to use the CPSUserFolder +
metadirectories + etc solution.

Now from what I saw (I may  have missed some points, but...), we
concluded that using LDAPUserGroupsFolder, at least for the first
rounds, would be much more manageable - we (well... I) only forgot that
aquisition could come in the way :(

> Of course, looking for a hack to deliver your project can always be
> solution ;)

I'm afraid it's the only short-term solution we have.

-- 
Bruno Desthuilliers
Développeur
bruno at modulix.org