[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapo-dynlist search member=value search?

Pierangelo Masarati pisze:
You can't put in the filter information that has to be generated dynamically, like dynamic group membership. Or, you could, but then any search would need to be split into:

- search the whole database for (objectClass=*) to trigger dynamic expansion of data; then
- search the (at this point, unindexed) dynamically generated data. This could be implemented, but probably it's not what users want...
I thought that it works exactly like this, and I think this is what users want and expect (e.g. see the post "Dynamic Group overlay with ldapsearch for uniquemember oddity" from march 2006 by Michael Heep).

Groups are almost unusable if they don't work both ways since the necessary operations for a group-based authorization subsystem are both: mapping a group to member users and mapping a user to groups he's a member of.

For example, see Zope/Plone LDAP Multi Plugin (http://plone.org/products/ploneldap): it needs the following functionalities for LDAP groups to work properly (the names should be self-explanatory): enumerateGroups, getGroupsForPrincipal, enumerateUsers.

I believe that nss_ldap also does both types of search.

I imagined that OpenLDAP maintained a cache for dynamic groups (that's how I understood "this exploits slapd group caching capabilities" in the FAQ) in order to do a search on (member=member'sDN).
Such a cache would only need updating in only two cases:

  1. when there's a change in an object's DN if the object has an
     attribute used in any memberURL
  2. when there's a change in any object in any attribute that's used
     in a filter in any memberURL in the directory (sorry for
     convoluted sentence, but it's a convoluted subject...).

When I think about it, this data should be permanent, so it should be kept in an index, not in memory cache.

Yes, there's some complex logic involved here (e.g. there needs to be a list kept updated with names of all the attributes that are used in memberURL filters) and it cannot posibly work for non-local memberURLs (those that specify a different LDAP server). But this is theoretically possible and would make dynlist usable for group memberships, not only for mail aliases (like currently).

Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575 http://olo.org.pl

Aleksander Adamowski
Administrator systemów korporacyjnych; Instruktor
Altkom Akademia S.A. http://www.altkom.pl
Warszawa, ul. Chłodna 51
kom. 0-601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is prohibited.
If you received this message by mistake, please contact the sender immediately and delete all copies of this message.