[SPIP Zone] Formidable, identification http

Salut à tous,
cela fait quelques temps que je travaille sur quelques améliorations de Formidable, dont j'ai besoin pour réaliser des formulaires de sondages.
J'ai remonté ici un problème que l'on avait dans l'authentification des utilisateurs.

Dans le cadre d'un formulaire à réponse unique, modifiable à volonté, je me suis rendu compte d'une limite de Formidable (RastaPopoulos, arrête-moi si je me trompe) :
afin de retrouver les précédentes réponses d'un utilisateur, on peut configurer le formulaire pour qu'il retrouve la personne soit :
- à partir d'un cookie
- à partir de son id_auteur

La première solution est simple parce qu'elle ne fait pas appel à la base de données et n'oblige pas l'utilisateur à obtenir un id_auteur. Mais si une personne change de poste pour retrouver ses réponses, le cookie étant différent, le formulaire apparaît comme vierge et bref, les données ne sont pas retrouvées.

La seconde solution est la plus fiable, étant donné qu'elle va rechercher l'id_auteur de l'utilisateur et recherche dans la base, la réponse correspondant à cet auteur.
Mais cette solution a une limite. On ne connaît pas l'id_auteur si l'utilisateur n'a aucun cookie du site SPIP et s'il ne s'est pas authentifié en passant dans l'espace privé, ou en remplissant le formulaire de connexion.

J'ai patché Formidable il y a quelques temps pour qu'il appelle des fonctions d'authentification ( auth_dist() ). Cela fonctionnait relativement bien, mais je me suis heurté à une nouvelle limite.

Un utilisateur n'étant pas enregistré dans SPIP ne possède pas d'id_auteur. Du coup, il est impossible de retrouver un utilisateur n'étant pas passé par l'espace privé, ou n'ayant pas rempli correctement le formulaire de login par son id_auteur. Les réponses ne peuvent donc plus être uniques et révisables.

Nos sites web se trouvent derrière une application SSO et le serveur fournit pas mal de variables (REMOTE_USER) permettant une authentification HTTP...
Nous voudrions ajouter l'authentification HTTP et remonter la contrib. Cela influerait sur ma précédente contrib (non commit) traitant sur les formulaires anonymes (supportant toujours les réponses uniques révisables).

Nous avons fait un patch quick-and-dirty de Formidable :
dans le cas d'un formulaire à authentification par cookie, si $_SERVER['REMOTE_USER'] est valué, c'est cette valeur (un login unique, donc) qui est utilisée et placée dans le champ 'cookie' de la table spip_formulaires_reponses. Pas top mais ça marche !

Questions :

- un tel type d'authentification a-t-il sa place comme contrib dans Formidable ?
- le comportement actuel (REMOTE_USER -> cookie) est-il satisfaisant et faut-il juste le documenter (je me doute de la réponse) ?
- faudrait-il plutôt créer un nouveau champ (type HTTP_auteur) dans la table spip_formulaires_reponses ?
- je me lance dans la modif ?
- ça a une chance d'être un jour remonté ?
--
Camille *Sauvage*

Le 11/03/2013 14:58, Camille Sauvage a écrit :

Dans le cadre d'un formulaire à réponse unique, modifiable à volonté, je
me suis rendu compte d'une limite de Formidable (RastaPopoulos,
arrête-moi si je me trompe) :
afin de retrouver les précédentes réponses d'un utilisateur, on peut
configurer le formulaire pour qu'il retrouve la personne soit :
- à partir d'un cookie
- à partir de son id_auteur

Ce n'est pas "soit" : ça fait toujours les deux. Mais on peut choisir l'ordre dans lequel on préfère que ce soit testé.

Questions :

- un tel type d'authentification a-t-il sa place comme contrib dans
Formidable ?
- le comportement actuel (REMOTE_USER -> cookie) est-il satisfaisant et
faut-il juste le documenter (je me doute de la réponse) ?
- faudrait-il plutôt créer un nouveau champ (type HTTP_auteur) dans la
table spip_formulaires_reponses ?
- je me lance dans la modif ?
- ça a une chance d'être un jour remonté ?

Je pense clairement qu'il ne faut pas tout mélanger. En quoi Formidable a un rapport direct avec l'authentification ? Il faut le minimum de dépendance à mon avis, et ne pas tout mélanger.

J'ai plutôt l'impression que ce qu'il faudrait, ce serait d'authentifier *réellement* les gens sur votre SPIP avec le SSO. Car là il y a des API pour ça et les méthodes d'auth de SPIP sont prévues d'office pour êtres extensibles.

Donc peut-être faire un plugin qui identifie vos utilisateurs sur votre SPIP grâce au SSO (et qui leur crée un compte utilisateur et donc un id_auteur s'il n'existe pas déjà, comme le fait l'auth openid ou facebook). Après si en plus c'est un SSO "standard" (un truc qui existe chez d'autres), ben ya même moyen de distribuer ce plugin. Mais même si ce n'est pas le cas, ça reste à mon avis le plus propre.

À partir de là, les gens sont vraiment logués sur le SPIP, et peuvent donc être identifiés à coup sûr.

Et si vraiment rien de tout ça n'est possible (mais pour l'instant je crois que si) et bien il faudra plutôt réfléchir à rendre le noyau de Formidable plus extensible sur ces points (en ajoutant des pipelines et/ou des appels à des fonctions spécifiques modifiables), ce qui permettra alors à des plugins externes de modifier le comportement par défaut (même si ces besoins sont génériques et distribuables sur la zone).

--
RastaPopoulos

Le 11/03/2013 16:40, RastaPopoulos a écrit :

Je pense clairement qu'il ne faut pas tout mélanger. En quoi Formidable
a un rapport direct avec l'authentification ? Il faut le minimum de
dépendance à mon avis, et ne pas tout mélanger.

Je suis d'accord avec toi. J'ai mis le temps mais il est vrai que l'objectif de Formidable n'est vraiment pas de forcer l'authentification. Mais il faut quand-même garder à l'esprit que les formulaires à réponse unique (modifiables ou non) dépendent d'une info qui n'est pas totalement garantie par SPIP.

Pour ma part, j'ai créé une balise #FORCE_AUTH visible ici :
http://pastebin.com/vkwmvpgK

Elle me sert désormais dans les squelettes nécessitant que l'utilisateur aie un id_auteur. On pourrait l'améliorer aisément pour la transformer en #FORCE_AUTH{6comite} pour demander que le statut par défaut des utilisateurs créés/importés en base soit paramètrable.

J'appelle également la balise en PHP depuis le pipeline "formulaire_charger" :
function pipeline_formulaire_charger($flux) {
   if ($flux['args']['form'] == 'formidable') {
     $force_auth = include_spip('balise/force_auth');
     balise_FORCE_AUTH_dyn('');
   }
}

Et si vraiment rien de tout ça n'est possible (mais pour l'instant je
crois que si) et bien il faudra plutôt réfléchir à rendre le noyau de
Formidable plus extensible sur ces points (en ajoutant des pipelines
et/ou des appels à des fonctions spécifiques modifiables), ce qui
permettra alors à des plugins externes de modifier le comportement par
défaut (même si ces besoins sont génériques et distribuables sur la zone).

Bin en fait, je trouve que les 3 pipelines du CVT sont déjà très complets et utiles. J'y réfléchirai à deux fois avant de proposer des extensions de Formidable, qui fait formidablement bien son boulot (exit forms et tables !!!!).

Et cette anonymisation ??

Merci pour tous tes conseils.
--
Camille

Le 14/03/2013 15:38, Camille Sauvage a écrit :

Et cette anonymisation ??

Je n'ai toujours pas le temps de me repencher sur le code de Formidable en ce moment (juste répondre à des mails de temps en temps).

Mais en revanche, spip-zone est un dépôt ouvert à tous (suffit de demander un compte dans un sujet séparé si tu n'en as pas déjà un), et tu peux commiter dessus si ça ne casse rien à l'existant et si ça ne complique pas trop l'interface.

--
RastaPopoulos