This commit fix an error happening when the subadmin tries to create an
user, adding him/her to the group s/he is subadmin of, using a LDAP
User/Group plugin.
This just forces the cache to be reset after an user is added to a
group.
Signed-off-by: Vinicius Cubas Brand <viniciuscb@gmail.com>
Nested groups are now cached in a CappedMemoryCache object to reduce
queries to the LDAP backend.
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
The previous patch fixed the problem only for one level of indirection
because groupsMatchFilter() had been applied on each recursive call (and
thus there would be no second level if the first level fails the check).
This new implementation replaces the recursive call with a stack that
iterates all nested groups before filtering with groupsMatchFilter().
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
Currently groupsMatchFilter is called before nested groups are resolved.
This basicly breaks this feature since it is not possible to inherit
membership in a group from another group.
Minimal example:
Group filter: (&(objectClass=group),(cn=nextcloud))
Nested groups: enabled
cn=nextcloud,ou=Nextcloud,ou=groups,dn=company,dn=local
objectClass: group
cn=IT,ou=groups,dn=company,dn=local
objectClass: group
memberOf: cn=nextcloud,ou=Nextcloud,ou=groups,dn=company,dn=local
cn=John Doe,ou=users,dn=company,dn=local
objectClass: person
memberOf: cn=IT,ou=groups,dn=company,dn=local
Since 'cn=IT,ou=groups,dn=company,dn=local' doesn't match the group
filter, John wouldn't be a member of group 'nextcloud'.
This patch fixes this by filtering the groups after all nested groups
have been collected. If nested groups is disabled the result will be the
same as without this patch.
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
For #24403
When upgrading huge installations this can lead to memory problems as
the cache will only grow and grow.
Capping this memory will make sure we don't run out while during normal
operation still basically cache everything.
