Version 3 — Novembre 2018 — 78.242.xx.xx
Voir aussi : AuthentificationDansSpip
Cerd : En gros je pense que la meilleure solution aujourd’hui c’est d’implémenter un serveur Oauth2 qui utilise les comptes d’un SPIP central, et ensuite les clients utilisent du SSO en client Oauth2, ce qui est assez classique.
In vivo on le fait dans le plugin magiclogin pour se loger avec Twitter ou avec FB, ce qui est presque pareil aux spécificités propres à chaque plateformes, in vitro j’ai quelque part une implémentation de login client Oauth2 standard que je peux partager si besoin - mais il reste la partie serveur à faire, sans doute en utilisant une lib qui va bien…
bz : J’aime bien cette idée, mais concrètement pour l’utilisateur qu’est-ce que ça donne ?
J’imagine que la première fois il arrive sur le site A du réseau, il créé un compte car il n’en a pas. En fait le compte est crée sur le serveur central Oauth2, puis la connexion est activée sur le site client, parfait.
Ensuite l’utilisateur se rend sur le site B du réseau, il n’est pas connecté. Que fait-on à ce moment là pour utiliser le compte existant sur le serveur central ? Un bouton "se connecter avec SPIP" ?
Cerd : Je pense que le seul petit point délicat c’est en effet la création du compte sur le site central, qui, a priori, ne peut pas de faire via un site client : il faut passer sur le site central pour se créer un compte
Après une fois cela fait, sur les sites client on a un bouton « Se connecter avec ‘le nom du site central’ » qui t’envoie sur le login de ce site.
Si tu es pas du tout connecté sur le site central il faut le faire la première fois, et les autres vois il vérifie juste qu’il a bien une session pour toi, et qu’elle est valide, et te redirige vers le site client.
ptux : erational : pour le SSo je suis aussi à la recherche de ça mais sans LDAP derrière
era : pareil
era : avec un gestion master / slave ou autre ou un site spip qui ne fait que gérer l’authentification
era : j’ai lancé l’email car il y a surement des gens ont commencé des trucs ds leur coin
ptux : j’ai pour le moment monter un flux rss qui syncronise les compte + mdp pour avoir les profil identique mais il faut se loguer des 2 côté
ptux : j’en avais parler ici avec cerdic il me semble pour que ça logue sur les 2 sites en même temps c’est pas simple
era : oui je sais que ce n’est pas simple
ptux : et pour 2000 comptes ça complique les choses ;)
era : ca ce n’est pas pb car tu peux tjs avoir un genie qui fait la synchro
era : en détectant les changements
ptux : oui c mon cas pour les comptes, mais pas les session
ptux : je fais le genie que dans 1 sens par contre erational, pas les 2
era : oui je pensais a cela
era : avoir un 2e login mais avec le mm compte est un moindre mal
era : ce n’est pas élégant mais c’est mieux que d’avoir 2 comptes
ptux : non moi c’est identique obligatoirement
ptux : id_auteur + login doit être identique sur les 2 sites
era : oui je me suis mal exprimé
era : je voulais éviter d’avoir a se loguer une nouvelle fois
era : mais avec le mm couple login/pwd
ptux : pour le moment je suis sur le meme serveur mais l’idéal serait de pouvoir géré sur 2 serveurs
gz : avec la mm table spip_auteurs des 2 cotés (mysql pourrait gérer ca imho)
et un montage réseau commun pour tmp/session et tmp/visites ca peut peut être marcher
ptux : non, dans le fichier session c’est pas identique
ptux : tu as un clé par rapport au domaine logiquement - sinon je l’aurais déjà fais
gz : ah beh la ca le serait
ptux : ça veut dire que je pourrais coppier mon ficher session perso sur d’autre site que je gère et ça me logue sans rien de plus ?
gz : https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/session.php#L643
bz : erational : c’est un bon sujet le SSO, j’ay arrive avec deux techniques
era : oui ?
gz : je testerai un share réseau avec un $GLOBALS[’meta’][$alea] commun (idem, c’est stocké en DB derrière, donc replicat mysql ou autre)
bz : une avec un spip central qui fait l’identification, puis renvoi sur le site appelant
bz : et la le site apellant affihe dans des iframes invisibles des actions d’autres sites du réseaux
bz : et tout le monde est connecté
gz : et bien penser a fixer _COOKIE_DOMAIN a tous les dom qui doivent le use mabon
era : oui j’ai pensé un site dedie a la gestion de comptes
era : on a une page sur wiki sur SSO ?
era : yapluka
bz : mais c un peu crade les iframes invisibles
ptux : site dedie ça peut etre n’importe le quel du groupe erational ?
era : https://contrib.spip.net/AuthentificationDansSpip
bz : l’autre technique c’est avec un site central qui identifie en OAuth 1.0 avec des jetons
bz : et on propage un cookie entre des ous domaines sur le MEME DOMAINE
bz : plus classe mais ca marche que sur le meme domaine
era : c’est le pb sur domaine unique
ptux : meme domaine donc ça marche en sous domaine
bz : sinon on peut renvoyer en http sur une boucle de tous les sites, mais si y’en a un qui pete
bz : ben ca nique tout
bz : bref j’ai pas de super soluce
era : « car l’algorithme de cryptage utilisé (hash MD5) ne possède actuellement pas de méthode de décryptage. »
era : on utilise un sel qd mm car le md5 ca se break qd mm
bz : on est plus en md5
era : ouf donc
ptux : faut copier 3 champs de la bdd pour avoir le mot de passe de l’auteur
</blockquote>Extrait d’IRC
<blockquote class="spip">
* Chourak ( Thunderbi@2a01cb0d003f0c00b016b44483bd3036.ipv6.abo.wanadoo.fr) vient de rentrer
* asr a donné la parole à Chourak
* Edgard a quitté (Remote host closed the connection)
* Edgard ( Edgard@2001:41d0:203:12a: :) vient de rentrer
* asr a donné la parole à Edgard
* pierretux sinon je l’aurais déjà fais
* ludo2 ( Thunderbi@236-17-127-151.dsl.ovh.fr) vient de rentrer
* asr a donné la parole à ludo2