Re: La boucle LDAP needs YOU
davux <da <at> weeno.net>
2011-01-02 02:31:49 GMT
02/01/11, Fil:
> > Un exemple de boucle "idéale" :
> > BOUCLE_albert_alex(LDAP){objectClass=person}{displayName=Al*}
> >
>
> en quoi serait-ce supérieur à la
> <boucle(DATA){datasource ldap: configuration du ldap
> &objectClass=person&displayName=Al*}> ?
Fonctionnellement c'est équivalent. Ça serait simplement moins verbeux,
(et peut-être plus rapide). Comme tu le dis, pour une utilisation
ponctuelle c'est équivalent. Pour une utilisation plus intense, par
exemple utiliser le LDAP comme source de données pour plein de choses
du site, ça commencerait à être intéressant d'avoir une boucle native.
> > Le filtre serait cette fois, évidemment:
> > |(displayName=Al*)(displayName=Bob*)
> >
>
> C'est une notion de OU ? Les critères de SPIP sont des ET...
Justement, c'est pour ça que dans le cas du OU, toute la condition est
dans un seul critère (regarde bien l'exemple de boucle que j'ai donné).
Seuls les ET peuvent être séparés sur plusieurs critères.
Pour le dire autrement :
- Le cas général serait : BOUCLE(LDAP){xxx}, où xxx est un filtre LDAP
complet.
- Dans le cas où le filtre peut être écrit sous la forme
&(aaa)(bbb), on _pourrait_ écrire BOUCLE(LDAP){aaa}{bbb}, sans que
ce soit pour autant obligatoire. Ça serait juste plus pratique à
l'usage.
> > En ce qui concerne le host, je pense qu'il est inutile de le
> > mentionner dans la boucle, il suffit de réutiliser celui qui est
> > configuré pour l'authentification par exemple. La gestion des
> > serveurs multiples est même plus simple qu'en SQL car on peut
> > configurer le serveur LDAP lui-même pour déléguer vers d'autres
> > serveurs, ce qui fait que pour SPIP un seul serveur LDAP est
> > normalement suffisant.
> >
>
> Pas vraiment d'accord. Suppose que mon site ait pour seul objectif de
> publier l'annuaire LDAP de mon association. L'authentification n'a
> rien à voir avec ça. En revanche mes *données* sont dans un
> répertoire LDAP, et je veux aller les chercher.
Je mentionnais l'authentification car c'est le seul usage qui est fait
de LDAP dans SPIP actuellement, mais j'aurais dû dire qu'on peut
réutiliser la "source actuelle de définition du LDAP". C'est vraiment
rare qu'on ait à taper dans plusieurs annuaires, et dans ces rares cas,
une boucle DATA prenant une URI complète est toujours possible. Par
ailleurs, OpenLDAP par exemple peut être configuré pour déléguer
certaines branches à des annuaires LDAP externes, ce qui permet de ne
gérer qu'un seul annuaire au niveau de SPIP, tout en tapant en
réalité dans plusieurs annuaires.
Pour éviter tout quiproquo, j'en profite pour rappeler qu'une base LDAP
est une base de données comme une autre (sauf qu'elle n'est pas
relationnelle). On peut donc bien sûr l'utiliser comme annuaire d'asso,
comme source d'authentification, mais aussi pour tout ce qu'on veut,
par exemple pour stocker le contenu complet d'un site (j'ai en tête un
début de schéma LDAP à ce sujet). Il serait donc très intéressant, à
l'instar des bases SQL, de fournir un outil de consultation d'une telle
base de données qui en permette une utilisation intensive simplement,
contrairement à une boucle DATA qui, elle, serait amplement suffisante
pour un usage ponctuel (2 ou 3 boucles dans tout le site).
--
davux
02/01/11, Fil:
> > Un exemple de boucle "idéale" :
> > BOUCLE_albert_alex(LDAP){objectClass=person}{displayName=Al*}
> >
>
> en quoi serait-ce supérieur à la
> <boucle(DATA){datasource ldap: configuration du ldap
> &objectClass=person&displayName=Al*}> ?
Fonctionnellement c'est équivalent. Ça serait simplement moins verbeux,
(et peut-être plus rapide). Comme tu le dis, pour une utilisation
ponctuelle c'est équivalent. Pour une utilisation plus intense, par
exemple utiliser le LDAP comme source de données pour plein de choses
du site, ça commencerait à être intéressant d'avoir une boucle native.
> > Le filtre serait cette fois, évidemment:
> > |(displayName=Al*)(displayName=Bob*)
> >
>
> C'est une notion de OU ? Les critères de SPIP sont des ET...
Justement, c'est pour ça que dans le cas du OU, toute la condition est
dans un seul critère (regarde bien l'exemple de boucle que j'ai donné).
Seuls les ET peuvent être séparés sur plusieurs critères.
Pour le dire autrement :
- Le cas général serait : BOUCLE(LDAP){xxx}, où xxx est un filtre LDAP
complet.
- Dans le cas où le filtre peut être écrit sous la forme
&(aaa)(bbb), on _pourrait_ écrire BOUCLE(LDAP){aaa}{bbb}, sans que
ce soit pour autant obligatoire. Ça serait juste plus pratique à
l'usage.
> > En ce qui concerne le host, je pense qu'il est inutile de le
> > mentionner dans la boucle, il suffit de réutiliser celui qui est
> > configuré pour l'authentification par exemple. La gestion des
> > serveurs multiples est même plus simple qu'en SQL car on peut
> > configurer le serveur LDAP lui-même pour déléguer vers d'autres
> > serveurs, ce qui fait que pour SPIP un seul serveur LDAP est
> > normalement suffisant.
> >
>
> Pas vraiment d'accord. Suppose que mon site ait pour seul objectif de
> publier l'annuaire LDAP de mon association. L'authentification n'a
> rien à voir avec ça. En revanche mes *données* sont dans un
> répertoire LDAP, et je veux aller les chercher.
Je mentionnais l'authentification car c'est le seul usage qui est fait
de LDAP dans SPIP actuellement, mais j'aurais dû dire qu'on peut
réutiliser la "source actuelle de définition du LDAP". C'est vraiment
rare qu'on ait à taper dans plusieurs annuaires, et dans ces rares cas,
une boucle DATA prenant une URI complète est toujours possible. Par
ailleurs, OpenLDAP par exemple peut être configuré pour déléguer
certaines branches à des annuaires LDAP externes, ce qui permet de ne
gérer qu'un seul annuaire au niveau de SPIP, tout en tapant en
réalité dans plusieurs annuaires.
Pour éviter tout quiproquo, j'en profite pour rappeler qu'une base LDAP
est une base de données comme une autre (sauf qu'elle n'est pas
relationnelle). On peut donc bien sûr l'utiliser comme annuaire d'asso,
comme source d'authentification, mais aussi pour tout ce qu'on veut,
par exemple pour stocker le contenu complet d'un site (j'ai en tête un
début de schéma LDAP à ce sujet). Il serait donc très intéressant, à
l'instar des bases SQL, de fournir un outil de consultation d'une telle
base de données qui en permette une utilisation intensive simplement,
contrairement à une boucle DATA qui, elle, serait amplement suffisante
pour un usage ponctuel (2 ou 3 boucles dans tout le site).
--
--
davux
George
RSS Feed