So the overlay operates on entries *returned* by a search, and thus it has nothing to do with the search filter. At the time of filtering, the dynamic values are not present in the entry, and thus cannot match.
ok, but how can this be solved without to have to maintain the group tree with static members and to have the ability to search for member=.. ?
This can't be solved. There's a blatant contradiction between pretending membership to be dynamic and pretending that indexes are maintained about something that is dynamically generated. Please note that this discussion already took place innumerable times. Please search the list archives (openldap-software and openldap-technical) for further reading.
slapo-dynlist was designed to fulfill a specific requirement, which makes perfectly sense:
- expand URIs into an entry that merges the results of a subsearch - allow to compare on dynamically generated attributes.
The fulfillment of latter requirement allows dynamic groups to perform their main functionality, which consists in allowing to check whether a given DN is member of a given group. It does not allow to find what groups a given DN is member of, but I think the latter is an improper use of LDAP groups.
i thought about a proxy cache but this would probably be senseless because a proxytemplate (member=) would result in nothing to cache because of the target server?
Exactly.
p.