Can I re-use one memcached instance for multiple Plone sites if they connect to the same LDAP/AD

[fredvd]

Something I've been wondering for a while and I'd like to add to the docs.

[jensens]

It caches the answer to an query and the cache key is n fact the BindDN, BaseDN, query and some additional data. https://github.com/bluedynamics/node.ext.ldap/blob/48377a52e9a31e2bb71106c47f0dc8ac67e8ae2a/src/node/ext/ldap/base.py#L245-L255

So, if the BindDN or BaseDN is different: No problem. Otherwise better not.

[rnixx]

The cache key gets created from all relevant LDAP node configuration and query state parameters. Where do you see a problem with the same configuration on multiple Plone instances? Actually it's the same user base then.

[jensens]

In fact that is what I wrote in different words.

[rnixx]

Otherwise better not.

What do you mean then?

[jensens]

What do you mean then?

The rare case one has two different LDAP configured exactly the same with different data in, like a staging server and a live server sharing the same Memcached.

[jensens]

@fred, would you add the answer to the README?

[mauritsvanrees]

From the above comments, I am not sure what the answer would be.

The use case is:

• A server has several Plone Sites, say three, each in their own buildout, their own ZEO server. So completely separate.
• All have the exact same LDAP setup, except that they currently each have their own memcache server, which is on the same machine as the Plone Sites are on.

Could they share the same memcache?

I cannot imagine this going wrong for authentication, or for listing users. But perhaps something can go wrong if user John has the global admin role or local Editor role in one site, and has no special roles on the other sites? I am simply thinking of roles assigned in Plone, not any roles or groups taken over from LDAP.

Do you see a danger there?

[fredvd]

I asked Maurits to read this thread as well because I couldn't draw a conclusion yet.

So if you have a test and production Plone set up and each connects to a test and production LDAP you can share the same cache because the key is different.

As Maurits much better described, the usecase why we asked this is to actually share the cache data between the instances. I didn't think of local roles yet, I was more concerned about concurrent writes for the same query results by different Plone sites in the memcached.

[jensens]

The use case is: [... see above ...] Could they share the same memcache?

Yes.

Do you see a danger there?

No. In worst case

• Plone A reads, can not find the value, starts LDAP request
• Plone B reads, can not find the value, starts LDAP request,
• Plone A writes to memcached
• Plone B (overrides) writes to memcached with same result.

[rnixx]

@mauritsvanrees @fredvd

But perhaps something can go wrong if user John has the global admin role or local Editor role in one site, and has no special roles on the other sites?

node.ext.ldap supports global roles from LDAP. But this functionality is NOT implemented in pas.plugins.ldap at all.

So all global and local roles are stored in the ZODB for each instance.

I see no reason why cached LDAP query results should affect role assignment in different Plone instances.

[fredvd]

@rnixx @jensens Thanks! I'll test it this week and prepare a docs update.