Est-ce que les utilisateurs de ldap peuvent confirmer que ce morceau de code ne servait pas, ou qu'au contraire cela cachait quelque chose a faire remonter dans l'API ?
Cédric
Cette variable servait normalement à donner le statut par défaut d'un connecté par LDAP.
Perso, comme je surcharge ça je n'en ai pas *effectivement* l'usage, mais il est a priori anormal
que son utilisation ait disparu au cours du temps.
Committo,Ergo:Sum
En fait c'est ce dépot-ci qui a rendu intutile ce paramètre:
http://trac.rezo.net/trac/spip/changeset/8659/spip/ecrire/inc/editer_auteurs.php
est-ce légitime, je ne saurais dire.
Committo,Ergo:Sum
Est-ce que les utilisateurs de ldap peuvent confirmer que ce morceau de code ne servait pas, ou qu'au contraire cela cachait quelque chose a faire remonter dans l'API ?
une reference a un ldap_statut_import qui sert a fournir une variable $statut inutilisee.
Cette variable servait normalement à donner le statut par défaut d'un connecté par LDAP.
Perso, comme je surcharge ça je n'en ai pas *effectivement* l'usage, mais il est a priori anormal
que son utilisation ait disparu au cours du temps.
La globale sert encore dans auth/ldap pour ajouter au site quelqu'un qui se log via ldap sans être encore dans spip_auteurs.
Mais dans inc/editer_auteur, je me demandais si implicitement cela supposait qu'on pouvait choisir des auteurs dans l'annuaire ldap, même si non encore présent dans SPIP, et que dans ce cas ils y seraient ajoutes automatiquement.
Si il s'agit de quelque chose comme cela, il faudrait deleguer a l'api auth le soin de lister les auteurs potentiels et l'inscription auto le cas écheant.
Mais a part ce morceau de code je n'ai rien vu d'autre qui ferait penser à ça.
En fait c'est ce dépot-ci qui a rendu intutile ce paramètre:
http://trac.rezo.net/trac/spip/changeset/8659/spip/ecrire/inc/editer_auteurs.php
est-ce légitime, je ne saurais dire.
3ans, on va donc dire qu'il y a prescription.
L'autre chose qui me gêne dans Ldap est que la conexion a Ldap semble mélangée avec la connexion a la base SPIP par l'api SQL.
J'avoue ne pas très bien comprendre ce point d'architecture, et je ne vois pas très bien comment généraliser et déporter les bonnes fonctions dans auth/ldap.
Il me semble que la connexion a l'annuaire LDAP devrait être du ressort exclusif de auth/ldap.
Cédric
Je ne comprends pas à quoi tu fais référence.
Committo,Ergo:Sum
http://trac.rezo.net/trac/spip/browser/spip/ecrire/base/connect_sql.php#L211
et
http://trac.rezo.net/trac/spip/browser/spip/ecrire/base/connect_sql.php#L148
que l'on retrouve dans les req/
http://trac.rezo.net/trac/spip/browser/spip/ecrire/req/mysql.php#L18
http://trac.rezo.net/trac/spip/browser/spip/ecrire/req/mysql.php#L40
Je crois comprendre que le paramètre de connexion ldap est stocké dans config/connect.php, et passé a spip_connect_db, obligeant à le gérer dans toutes les implémentations de req/ alors que cela semble avoir peu de rapport avec le serveur sql lui même.
Cédric
Le fichier connect.php contient les infos déclarées à l'installation, en particulier si on utilise un serveur LDAP pour l'authentification. On ne peut pas se passer de cette info. En revanche, pour permettre le multi-serveur et la mutu, les parametres de connexion LDAP (adresse du serveur etc) sont mis dans un autre fichier, et le fichier connect.php ne contient comme info que le nom de ce fichier (par défaut "ldap.php" dans config/, nom vide voulant dire "pas LDAP"). Ensuite, depuis toutours connect.php (alias inc-connect etc) a consisté à appeler la spip_connect_db, avec les infos en question. Comme elle ne sait pas vraiment à quoi sert ce nom de fichier (son rôle est de se connecter au serveur SQL), elle va se contenter de le mémoriser dans la globale décrivant l'installation. Je ne vois pas ce que tu peux faire de plus simple, a fortiori sans casser la compatibilité du format du fichier connect.php.
En revanche, ce qui m'apparait plus clairement aujourd'hui c'est que le fichier ldap.php est incomplet.
A l'installation, il faudrait demander les champs à lire dans le serveur LDAP et à quoi ils correspondent dans la tables SQL des auteurs, en particulier le champ correspondant à login, et on mettrait ces infos dans ce fichier. Ensuite, la fonction spip_connect_ldap récupererait ces infos, afin que auth_ldap_search demande uniquement ces champs, plutôt que d'essayer tout jusqu'à temps d'avoir une réponse non vide.
La globale ldap_login_names introduit par http://trac.rezo.net/trac/spip/changeset/14608 est déjà un progrès puisqu'on peut la surcharger pour éviter les réponses vides, mais ça ne concerne que le champ login (pas email, nom etc), et l'architecture reste lacunaire en cas de multi-serveurs LDAP n'ayant pas nécessairement les mêmes nom de champs.
Committo,Ergo:Sum
Je crois comprendre que le paramètre de connexion ldap est stocké dans config/connect.php, et passé a spip_connect_db, obligeant à le gérer dans toutes les implémentations de req/ alors que cela semble avoir peu de rapport avec le serveur sql lui même.
Le fichier connect.php contient les infos déclarées à l'installation, en particulier si on utilise un serveur LDAP pour l'authentification. On ne peut pas se passer de cette info. En revanche, pour permettre le multi-serveur et la mutu, les parametres de connexion LDAP (adresse du serveur etc) sont mis dans un autre fichier, et le fichier connect.php ne contient comme info que le nom de ce fichier (par défaut "ldap.php" dans config/, nom vide voulant dire "pas LDAP"). Ensuite, depuis toutours connect.php (alias inc-connect etc) a consisté à appeler la spip_connect_db, avec les infos en question. Comme elle ne sait pas vraiment à quoi sert ce nom de fichier (son rôle est de se connecter au serveur SQL),
on est bien d'accord.
inc_connect.php était autrefois le fichier de configuration des connexions du site.
Avec l'apparition du multibase et des différents serveurs SQL possible, les fichiers connect.php et autres sont devenus les fichiers de description à la connexion d'une base SQL.
Voir un 'ldap.php' dedans est devenu un peu incongru, et le fait de stocker ce nom dans les paramètres du serveur SQL assez bizarre et source de questions pour qui découvre ce code.
elle va se contenter de le mémoriser dans la globale décrivant l'installation. Je ne vois pas ce que tu peux faire de plus simple, a fortiori sans casser la compatibilité du format du fichier connect.php.
Il me semble que de la même façon que config/connect.php est le fichier de connexion a la base principale,
config/ldap.php peut être par convention le fichier de connexion a LDAP sans devoir faire figurer ldap dans la connexion SQL.
Après, je ne sais pas si tu envisageais la construction intellectuelle d'appeler possiblement distinctement les serveurs LDAP associés à chaque base SQL. J'avoue avoir du mal à saisir le sens de ce type d'appel.
Pour la compatibilité, on peut se débrouiller pour garder de manière dérogatoire l'argument et le prendre en compte dans le cas ou il n'est pas ldap.php.
Mais je voudrais pouvoir déplacer tout ce qui concerne l'authentification ldap dans auth/ldap ou dans des fichiers qui ne concernent que LDAP (y compris à terme le process d'installation, mais ce point est peut être moins facile), pour avoir une séparation claire du code et pouvoir remplacer indifféremment Ldap par autre chose (par exemple, et au hasard, un annuaire SPIP centralisé auquel est délégué l'identification depuis des sites SPIP satellites).
J'essaye donc de faire ressortir les besoins en terme d'API et de distinguer le générique du particulier.
En revanche, ce qui m'apparait plus clairement aujourd'hui c'est que le fichier ldap.php est incomplet.
A l'installation, il faudrait demander les champs à lire dans le serveur LDAP et à quoi ils correspondent dans la tables SQL des auteurs, en particulier le champ correspondant à login, et on mettrait ces infos dans ce fichier. Ensuite, la fonction spip_connect_ldap récupererait ces infos, afin que auth_ldap_search demande uniquement ces champs, plutôt que d'essayer tout jusqu'à temps d'avoir une réponse non vide.
La globale ldap_login_names introduit par http://trac.rezo.net/trac/spip/changeset/14608 est déjà un progrès puisqu'on peut la surcharger pour éviter les réponses vides, mais ça ne concerne que le champ login (pas email, nom etc), et l'architecture reste lacunaire en cas de multi-serveurs LDAP n'ayant pas nécessairement les mêmes nom de champs.
Possible. Sur le point particulier du détail de LDAP je ne suis pas compétent.
Cédric
inc_connect.php était autrefois le fichier de configuration des connexions du site.
Avec l'apparition du multibase et des différents serveurs SQL possible, les fichiers connect.php et autres sont devenus les fichiers de description à la connexion d'une base SQL.
Voir un 'ldap.php' dedans est devenu un peu incongru, et le fait de stocker ce nom dans les paramètres du serveur SQL assez bizarre et source de questions pour qui découvre ce code.
Mais avant (SPIP <= 1.7) c'était pire: c'était le contenu de l'actuel fichier ldap.php qui se trouvait dans inc-connect, en plus de l'appel à spip_connect_db !
Il me semble que de la même façon que config/connect.php est le fichier de connexion a la base principale,
config/ldap.php peut être par convention le fichier de connexion a LDAP sans devoir faire figurer ldap dans la connexion SQL.
Après, je ne sais pas si tu envisageais la construction intellectuelle d'appeler possiblement distinctement les serveurs LDAP associés à chaque base SQL.
Si une base SQL délègue l'authentification à un serveur LDAP, les infos de connexion à ce serveur doivent faire partie de la description de cette base: je n'en ai pas l'utilisation, mais que chaque base SQL soit associée à des bases ou des droits de connexion LDAP différents ne semble pas absurde.
J'avoue avoir du mal à saisir le sens de ce type d'appel.
Pour la compatibilité, on peut se débrouiller pour garder de manière dérogatoire l'argument et le prendre en compte dans le cas ou il n'est pas ldap.php.
Je ne vois pas ce que tu vas gagner à casser la compat, sauf par plaisir de la construction intellectuelle.
Mais je voudrais pouvoir déplacer tout ce qui concerne l'authentification ldap dans auth/ldap ou dans des fichiers qui ne concernent que LDAP (y compris à terme le process d'installation, mais ce point est peut être moins facile), pour avoir une séparation claire du code et pouvoir remplacer indifféremment Ldap par autre chose (par exemple, et au hasard, un annuaire SPIP centralisé auquel est délégué l'identification depuis des sites SPIP satellites).
De nouveau ça pose le pb de savoir où tu retrouves l'info que l'authentification se fait dans tel annuaire pour cette installation.
La convention actuelle est que si spip_connect_db a un 8e argument non vide, c'est que l'authentification est en LDAP.
Si tu veux encore une autre authentification sans casser la compatiblité, je ne vois pas ce qu'on peut faire d'autre que d'ajouter un argument supplémentaire,
ce qui a d'ailleurs toujours été la manière d'enrichir cette fonction, je ne vois pas pourquoi il faudrait changer ça.
En revanche, ce qui m'apparait plus clairement aujourd'hui c'est que le fichier ldap.php est incomplet
...
Possible. Sur le point particulier du détail de LDAP je ne suis pas compétent.
ok, je vais approfondir de mon côté.
Committo,Ergo:Sum
Et pour une authentification CAS, on met un 9ème paramètre, puis un 10ème pour Shibolleth, puis... ainsi de suite ???
-Nicolas
Y a un truc important en développement logiciel qui se nomme la compatibilité ascendante, qui conduit à faire parfois une exception.
Enumerer des exceptions pour élaborer des règles, c'est de la comptabilité affligeante.
Committo,Ergo:Sum
inc_connect.php était autrefois le fichier de configuration des connexions du site.
Avec l'apparition du multibase et des différents serveurs SQL possible, les fichiers connect.php et autres sont devenus les fichiers de description à la connexion d'une base SQL.
Voir un 'ldap.php' dedans est devenu un peu incongru, et le fait de stocker ce nom dans les paramètres du serveur SQL assez bizarre et source de questions pour qui découvre ce code.Mais avant (SPIP <= 1.7) c'était pire: c'était le contenu de l'actuel fichier ldap.php qui se trouvait dans inc-connect, en plus de l'appel à spip_connect_db !
Il me semble que de la même façon que config/connect.php est le fichier de connexion a la base principale,
config/ldap.php peut être par convention le fichier de connexion a LDAP sans devoir faire figurer ldap dans la connexion SQL.
Après, je ne sais pas si tu envisageais la construction intellectuelle d'appeler possiblement distinctement les serveurs LDAP associés à chaque base SQL.Si une base SQL délègue l'authentification à un serveur LDAP, les infos de connexion à ce serveur doivent faire partie de la description de cette base: je n'en ai pas l'utilisation, mais que chaque base SQL soit associée à des bases ou des droits de connexion LDAP différents ne semble pas absurde.
La question sous-jacente est de savoir si c'est l'accès à la base qui est régi par l'authentification, ou l'accès à SPIP et à son back office.
Dans l'architecture actuelle, il est évident que c'est bien SPIP et son back office car aucun accès à une base distante n'est limité par les droits de l'auteur dans le référentiel de cette base distante.
Autrement dit, en tant qu'administrateur d'un site S avec une base B et un annuaire LDAP L, j'ai accès complet aux données d'un site T avec une base C et un annuaire M, indépendamment de la gestion des droits du site T.
Partant de là, je ne vois pas de lien entre la base C et l'annuaire M, mais bien entre T et C, et entre T et M, M étant éventuellement utilisé par T pour inscrire automatiquement des auteurs dans la base C.
L'ensemble de l'API autoriser() repose sur ce postulat.
J'avoue avoir du mal à saisir le sens de ce type d'appel.
Pour la compatibilité, on peut se débrouiller pour garder de manière dérogatoire l'argument et le prendre en compte dans le cas ou il n'est pas ldap.php.Je ne vois pas ce que tu vas gagner à casser la compat, sauf par plaisir de la construction intellectuelle.
Ne pas se limiter à LDAP, et avoir une API générique pour utiliser d'autres SSO ouverts (à commencer par OpenID) ou spécifiques.
Mais je voudrais pouvoir déplacer tout ce qui concerne l'authentification ldap dans auth/ldap ou dans des fichiers qui ne concernent que LDAP (y compris à terme le process d'installation, mais ce point est peut être moins facile), pour avoir une séparation claire du code et pouvoir remplacer indifféremment Ldap par autre chose (par exemple, et au hasard, un annuaire SPIP centralisé auquel est délégué l'identification depuis des sites SPIP satellites).
De nouveau ça pose le pb de savoir où tu retrouves l'info que l'authentification se fait dans tel annuaire pour cette installation.
C'est exactement comme pour connect.php => fichier de connexion a la base principale, ldap.php => fichier de connexion a l'annuaire LDAP du site
La convention actuelle est que si spip_connect_db a un 8e argument non vide, c'est que l'authentification est en LDAP.
Si tu veux encore une autre authentification sans casser la compatiblité, je ne vois pas ce qu'on peut faire d'autre que d'ajouter un argument supplémentaire,
ce qui a d'ailleurs toujours été la manière d'enrichir cette fonction, je ne vois pas pourquoi il faudrait changer ça.
Car ça n'est pas extensible et suppose donc de modifier le core à chaque fois qu'on veut ajouter un mécanisme SSO ou annuaire centralisé.
Cédric
+3 
Cédric
La question sous-jacente est de savoir si c'est l'accès à la base ...
Le pb c'est qu'il y a deux choses qu'il faut distinguer dans un site: la base SQL et ce que j'ai appelé dans mes mails l'installation.
Le fichier connect.php décrit l'installation, et il est indispensable.
La fonction qu'il appelle se nomme spip_connect_db, c'est peut-être un peu trompeur (et encore, "db" c'est très neutre), mais ça n'empêche personne de dormir.
....
L'ensemble de l'API autoriser() repose sur ce postulat.
mais "autoriser()" concerne les droits, alors que la discussion porte sur l'authentification, qu'est-ce que ça vient faire ici ?
Je ne vois pas ce que tu vas gagner à casser la compat, sauf par plaisir de la construction intellectuelle.
Ne pas se limiter à LDAP, et avoir une API générique pour utiliser d'autres SSO ouverts (à commencer par OpenID) ou spécifiques.
Tu aurais dû commencer par là.
On a une évolution assez classique: au départ SPIP ne délèguait pas l'authentification, donc il n'y avait rien de prévu. Ensuite, il est arrivé un truc nommé LDAP qui était la seule délégation d'authentification envisagée, donc on a ajouté un argument, qui ne pouvait avoir qu'une seule signification. Maintenant on veut gérér plusieurs types de délégation, donc ce qu'il faut c'est un couple de valeurs:
1. type de délégation
2. infos exploitables les fonctions associées (ou nom du fichier les contenant.
Donc il suffit de faire du 8e argument un array(type => fichier) en convenant que si c'est une chaîne, c'est équivalent à: array('ldap' => fichier).
Où est le pb ?
En tout cas, ne rien casser tant que l'installation n'a pas été retestée, y compris en mutualisée, parce que toute l'architecture actuelle repose sur ce qui se passe à ce moment là.
Committo,Ergo:Sum
De nouveau ça pose le pb de savoir où tu retrouves l'info que l'authentification se fait dans tel annuaire pour cette installation.
La convention actuelle est que si spip_connect_db a un 8e argument non vide, c'est que l'authentification est en LDAP.Et pour une authentification CAS, on met un 9ème paramètre, puis un 10ème pour Shibolleth, puis... ainsi de suite ???
Y a un truc important en développement logiciel qui se nomme la compatibilité ascendante, qui conduit à faire parfois une exception.
Clair.
Enumerer des exceptions pour élaborer des règles, c'est de la comptabilité affligeante.
Mais ça permet de voir à plus long terme en introduisant des mécanismes plus génériques.
-Nicolas
cedric.morin@yterium.com a écrit :
Ne pas se limiter à LDAP, et avoir une API générique pour utiliser d'autres SSO ouverts (à commencer par OpenID) ou spécifiques.
je n'ai pas encore regardé ca dans la 2, mais en 1.9, j'ai était confronté récemment au probleme
j'ai voulu faire un plugin d'authentification externe pour 2 besoins :
1- utiliser les utilisateurs d'un phpBB
2- utiliser les utilisateurs d'un SPIP central pour differents SPIP (avec l'authentification via le .htpasswd du SPIP central)
Dans les 2 cas, le but était de faire comme pour ldap : on copie l'utilisateur dans SPIP, sans mot de passe et avec dans source "authext" au lieu de "spip" ou "ldap"
Et ben je m'y suis un peu cassé les dents...
1- au stade de l'authentification, les plugins ne sont pas chargés, difficile donc de faire un plugin pour l'authentification...
2- pour "décrocher" de l'authentification classique de SPIP et permettre de rapatrier les comptes, j'ai été obligé de me brancher sur l'authentification ldap
3- la fonction lire_php_auth fait le test"!= 'ldap' au lieu de =='spip' => du coup impossible de faire un autre type de compte (pour moi authext)
aujourd'hui, j'ai réussit à faire marcher mon plugin moyennant une modif dans le core pour le 3 et l'ajout dans mes_options (qui lui est deja chargé) d'une fonction inc_auth_ldap qui test mon authentification externe avant de tester ldap.
Autre galère : le spip_path n'est pas encore construit, donc je suis obligé de faire :
include ((_DIR_RESTREINT?'':'../').'plugins/authext/inc/auth_authext.php');
include ((_DIR_RESTREINT?'':'../').'plugins/authext/base/central.php');
voila, c'est juste un petit retour sur ces question d'authentification externe, je ne sais pas si ca fait avancer le schmilblick...
@++
La question sous-jacente est de savoir si c'est l'accès à la base ...
Le pb c'est qu'il y a deux choses qu'il faut distinguer dans un site: la base SQL et ce que j'ai appelé dans mes mails l'installation.
Le fichier connect.php décrit l'installation, et il est indispensable.
oui
La fonction qu'il appelle se nomme spip_connect_db, c'est peut-être un peu trompeur (et encore, "db" c'est très neutre), mais ça n'empêche personne de dormir.
oui, mais c'est donc à ce niveau que la découpe n'a pas été complète puisque l'on devrait avoir d'un côté un appel a spip_connect_db pour connecter la base SQL, et un spip_connect_auth pour connecter la base d'identification
A minima on peut découper au niveau de spip_connect_db, en reroutant $ldap vers l'api inc/auth plutot qu'en la passant à req/*sql
....
L'ensemble de l'API autoriser() repose sur ce postulat.mais "autoriser()" concerne les droits, alors que la discussion porte sur l'authentification, qu'est-ce que ça vient faire ici ?
Juste que autoriser() repose exclusivement sur le contenu de la table spip_auteurs de la base principale, ce qui exclut tout lien potentiel avec l'authentification de la base distante de ce point de vue.
Je ne vois pas ce que tu vas gagner à casser la compat, sauf par plaisir de la construction intellectuelle.
Ne pas se limiter à LDAP, et avoir une API générique pour utiliser d'autres SSO ouverts (à commencer par OpenID) ou spécifiques.
Tu aurais dû commencer par là.
On a une évolution assez classique: au départ SPIP ne délèguait pas l'authentification, donc il n'y avait rien de prévu. Ensuite, il est arrivé un truc nommé LDAP qui était la seule délégation d'authentification envisagée, donc on a ajouté un argument, qui ne pouvait avoir qu'une seule signification. Maintenant on veut gérér plusieurs types de délégation, donc ce qu'il faut c'est un couple de valeurs:
1. type de délégation
2. infos exploitables les fonctions associées (ou nom du fichier les contenant.
Donc il suffit de faire du 8e argument un array(type => fichier) en convenant que si c'est une chaîne, c'est équivalent à: array('ldap' => fichier).
OK, on peut voir cela comme ça, en dispatchant de spip_connect_db vers l'api auth, sans plus passer vers les req/*sql
Où est le pb ?
En tout cas, ne rien casser tant que l'installation n'a pas été retestée, y compris en mutualisée, parce que toute l'architecture actuelle repose sur ce qui se passe à ce moment là.
Autant que faire se peut.
Je n'ai malheureusement pas d'installation LDAP qui me permette de valider cela, d'où toutes mes questions avant de toucher à ce morceau de code.
Cédric
c'est donc à ce niveau que la découpe n'a pas été complète puisque l'on devrait avoir d'un côté un appel a spip_connect_db pour connecter la base SQL, et un spip_connect_auth pour connecter la base d'identification
Pas vraiment parce que le NOM du fichier de connexion à la base SQL est contraint par le code de SPIP, tandis qu'on pourrait avoir le besoin d'un formulaire de déclaration LDAP ou autre annuaire qui calculerait un nom spécifique (autre que "config/ldap.php") lors de l'installation.
La fonction spip_connect_ldap appelle d'ailleurs spip_connect en lui communiquant le nom de l'installation pour savoir quel est le nom de ce fichier;
actuellement on ne s'en sert pas, mais si un jour on veut faire du multi-base avec accès en écriture, ça deviendra indispensable.
A minima on peut découper au niveau de spip_connect_db, en reroutant $ldap vers l'api inc/auth plutot qu'en la passant à req/*sql
Mais le besoin de se connecter à la base n'entraine pas celui d'authentifier: les visiteurs sont anonymes mais provoquent des calculs de page !
Tu vois ces fichiers comme symétriques alors qu'ils ne le sont pas.
Donc il suffit de faire du 8e argument un array(type => fichier) en convenant que si c'est une chaîne, c'est équivalent à: array('ldap' => fichier).
OK, on peut voir cela comme ça, en dispatchant de spip_connect_db vers l'api auth, sans plus passer vers les req/*sql
On peut en effet ne pas communiquer le 8e arg aux fonctions de portage, elles font toutes la même chose avec.
Actuellement il est mis dans l'index "ldap" du tableau de connexion, il vaudrait mieux le mettre dans l'index "authentification"
(mais garder l'ancien par souci de compatibilité).
Comme le signale Stéphane, les pbs sont ensuite dans la fonction lire_php_auth, que tu as remplacée par auth_identifier_login, mais en oubliant de renommer toutes ses occurrences dans inc/auth. Il faut complètement reprendre son code, en prenant le champ SQL "source", et en vérifiant que l'index "authentification" ci-dessus est bien un tableau dont l'index unique est égal à ce champ "source". Après, il faudra appeler la fonction "spip_connect_$source", ou rajouter cet appel par précaution dans les fonctions auth_$source.
Cela dit, avant de se lancer là-dedans, j'aimerais bien que les 2 bugs autour du bandeau, plus le pb de sa meta trop grosse, soient résolus: ça me bloque depuis un moment pour mes tests.
Committo,Ergo:Sum
Je rappelle que les mots clés et la syndication sont par défaut désactivés sur une installation vierge.
Le seul tort du bandeau était de proposer le boutons de création de mots clé avant que les mots clés ne soient activés.
http://trac.rezo.net/trac/spip/changeset/14616
La tentative de création de mot clé avant qu’un groupe n’existe provoquait elle une redirection infinie, corrigée par
http://trac.rezo.net/trac/spip/changeset/14615
Enfin, après que les sites syndiqués soient activés à leur tour, le bouton de creation de site ne doit s’afficher que lorsqu’une rubrique a été créée :
http://trac.rezo.net/trac/spip/changeset/14617
Le bandeau laissait donc faire trop de choses !
Cédric
Bon, donc les dépots de ces derniers jours ont réalisés ça et l'API autour de l'authentification s'enrichit.
Cela dit, il y reste toujours 2 pbs qui me chiffonent, et qui ne sont pas sans rapport mutuel.
1. Les fonctions résultants de l'appel charger_fonction(METHODE, 'auth') sont déclarées parfois avec un 2 paramètres (méthode ldap), parfois avec 4 (méthode spip), et l'appel en contient parfois 2 (install, lire_php_auth), parfois 4 (auth_identifier_login), et toute la combinatoire possible se produit. Il n'y a que PHP pour accepter un bazar pareil, et c'est assez incompréhensible pour le pékin moyen.
2. Le commentaire de la fonction auth_ldap_connect signale que son paramètre "serveur" sera toujours nul, mais en fait la remarque vaut pour la méthode d'authentification appelée "spip", qui fait des appels SQL sans préciser le serveur. Le scénario auquel il faudra bien se confronter un jour c'est celui de qq voulant répondre à un forum sur abonnement aperçu à travers une base externe: le formulaire de login devra appeler la fonction auth_identifier_login en lui communiquant le serveur dont il est question.
Ces deux points m'amènent à conclure que formulaires_login_verifier devrait remplacer les args 3 et 4 de l'appel auth_identifier_login par un seul, qui vaudrait _request('connect'), et les fonctions auth_spip et auth_ldap devraient avoir du coup un paramètre 3 pour recevoir cette indication du serveur considéré (ce qui résoud le point 1), et répercuter cette info en aval (ce qui résoud le point 2). Quant aux arg 3 et 4 qu'on laisse tomber dans l'appel, ce serait à auth_spip de les récupérer via _request. C'est certes un peu bancal, mais ça ne fait plus qu'un seul truc bizarre au lieu de 2, et pour un gain de fonctionnalité. De plus ce cas particulier est lié à la sécurité, pour laquelle on ne doit pas s'embarasser de considérations esthétique.
Any comments ?
Committo,Ergo:Sum