Fire group membership events from LDAP at login

[come-nc]

• Resolves: Sharing still broken with ldap groups #25062

Summary

Rework of #30512 to use new group membership mappings from #39446

TODO

• Fix it for the share accepting usecase

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[come-nc]

Here is the current state:

It crashes with:

Type : OC\Share20\Exception\ProviderException
Code : 0
Message : Recipient not in receiving group
Fichier : /var/www/html/lib/private/Share20/DefaultShareProvider.php
Ligne : 355

The problem is that the user<->group relation is cached in several places, and in this case there is a specific cache for inGroup.

So the cache should be emptied, but which one and when?
On top of redis, Group_LDAP uses some CappedMemoryCache instances to cache group members as well.

Also, clearing the whole cache each time a user logs in with a new group membership may be too often on big instances with tons of users and groups.

Another approach would be to add a method to add this specific user<>group relation ship to caches. I am gonna try this first.

[come-nc]

Another approach would be to add a method to add this specific user<>group relation ship to caches. I am gonna try this first.

This sounds complicated, there are these caches:

		/** @var CappedMemoryCache<string[]> $cachedGroupMembers array of users with gid as key */
		protected CappedMemoryCache $cachedGroupMembers;
		/** @var CappedMemoryCache<array[]> $cachedGroupsByMember array of groups with uid as key */
		protected CappedMemoryCache $cachedGroupsByMember;
		/** @var CappedMemoryCache<string[]> $cachedNestedGroups array of groups with gid (DN) as key */
		protected CappedMemoryCache $cachedNestedGroups;
		$cacheKey = 'inGroup' . $uid . ':' . $gid;
		$cacheKeyMembers = 'inGroup-members:' . $gid;
		$cacheKey = '_groupMembers' . $dnGroup;
		$cacheKey = 'getUserGroups' . $uid;
		$cacheKey = 'usersInGroup-' . $gid . '-' . $search . '-' . $limit . '-' . $offset;
		$cacheKey = 'usersInGroup-' . $gid . '-' . $search;
		$cacheKey = 'countUsersInGroup-' . $gid . '-' . $search;

The most problematic are usersInGroup search caches because we cannot easily know how many of them there are, and clearing by prefix is not working for Memcached, so not sure if it is ok to rely on it?
Maybe we can add the relationship to the other ones and ignore usersInGroup searches as it should not cause much damage to have outdated data in there.

[come-nc]

The most problematic are usersInGroup search caches because we cannot easily know how many of them there are, and clearing by prefix is not working for Memcached, so not sure if it is ok to rely on it? Maybe we can add the relationship to the other ones and ignore usersInGroup searches as it should not cause much damage to have outdated data in there.

I implemented this solution and it works.

[blizzz]

Not sure the logic really has to run with each login

[come-nc]

Not sure the logic really has to run with each login

If my analysis is correct, the groups are fetched to cache on each login anyway, so this does not add much overhead, it only compares with DB.

[nickvergessen]

/backport 500374a to stable27

[nickvergessen]

/backport 500374a to stable26

[nickvergessen]

/backport 500374a to stable25