Journal Partager les comptes utilisateurs entre différentes applications

Posté par  (site web personnel) .
Étiquettes : aucune
0
28
avr.
2004
Bonjour,
je voulais savoir s'il existe des techniques, des librairies ou n'importe quoi d'autres qui permettent de partager les utilisateurs entre différentes applications php.

Style : phpBB, SPIP, dotClear etc.

L'idée est de faire en sorte que les utilisateurs ne remplissent qu'une fois le formulaire et que quand ils se connectent à l'un, ils sont connecté aux autres.

Pour ma part, j'ai fait une appli php et j'ai voulu rajouté un forum, j'ai fait comme ceci :

une lib avec une fonction qui créer un compte sur phpBB (insert dans la table qui va bien), une fonction qui se log et une fonction qui créé un compte pour tous les comptes de l'autre appli qui n'avait pas été créé sous phpBB.

J'ai pas implémenté la destruction du compte phpBB, ni le fait de se délogguer etc.

Bref, c'est un peu dégueu (ça a été fait en vitesse, y'a même des pages de phpbb que j'ai viré pour éviter que les utilisateurs modifies leurs comptes...)

Bref, c'est pas top...

Si quelqu'un a des idées pour faire ça plus proprement, je suis preneur.

Axel

  • # Re: Partager les comptes utilisateurs entre différentes applications

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 04 décembre 2021 à 20:17.

    tout refaire a la main…

    C'est chiant, mais + fonctionnel, + souple et + clean…

    (http://templeet.org (NdM: remplacé en 2021 par un lien archive.org) )

  • # Re: Partager les comptes utilisateurs entre différentes applications

    Posté par  . Évalué à 1.

    Pour ce genre de truc on utilise plutôt LDAP, les applis web commencent à le prendre en compte (SPIP par exemple)

    Comme LDAP propose un schéma standard indépendant des applications, chacune peut s'y ratacher en ignorant les autres

    Une interface web pour créer les comptes : phpLdapAdmin
    Mais je ne crois pas qu'il permette à un anonyme de créer un compte, ce serait une améiloration intéressante

    Le seul problème est qu'LDAP est rare chez les hébergeurs

    pour le forum je te conseille fouletexte ( http://www.echodelta.net/scriptsphp/fouletexte/fouletexte.htm(...) ), il est très léger et s'intégre bien dans un site.
    Un de mes projets est de le reprendre pour le faire passer en css et LDAP

    • [^] # Re: Partager les comptes utilisateurs entre différentes applications

      Posté par  . Évalué à 1.

      > LDAP

      Tout a fait, je rajouterais qu'il serait plus utile pour toi d'aider les developpeurs à gérer une base commune (par exemple LDAP);
      comme ca, non seulement ton code sera conservé, mais en plus il sera utilisé par d'autres et maintenu.

      C'est pas la belle vie ? :)

      • [^] # Re: Partager les comptes utilisateurs entre différentes applications

        Posté par  (site web personnel) . Évalué à 1.

        Je connais pas trop LDAP, actuellement, les utilisateurs sont dans une table, mais beaucoup d'informations annexe se trouvent dans d'autres tables qui ont des clefs étrangeres qui pointe sur la table utilisateur, est ce que ça serait possible avec LDAP ?

        Axel

        • [^] # Re: Partager les comptes utilisateurs entre différentes applications

          Posté par  . Évalué à 1.

          Tout dépend de la facon dot ton systeme est organisé, tu peux par exemple recuperer leur UID dans LDAP et le réutiliser pour les identifier dans ta base.

        • [^] # Re: Partager les comptes utilisateurs entre différentes applications

          Posté par  . Évalué à 1.

          non, le modèle de données est différent, on ne peut pas appliquer à LDAP le modèle de données relationnel, ni même essayer de le traduire. Il faut repartir des specs initiales.

          En LDAP, les données sont hiérarchisées : l'annuaire a une racine, sous laquelle on peut mettre d'autres entrées, sous lesquelles on peut en mettre encore d'autres. Tu te constitues donc un annuaire avec des branches en plaçant sous la racine un objet de type "unité organisationnelle", que tu appelles par exemple "users", sous lequel tu places tes utiisateurs, qui sont eux de type "inetOrgPerson"

          Le type d'une entrée est une classe, qui définit quels attributs l'entrée doit ou peut implémenter. Selon la spécification de la classe utilisée, il n'est pas toujours obligatoire de renseigner une valeur (par exemple, le champ 'secretary' de inetOrgPerson n'est pas renseigné si la personne n'a pas de secrétaire), et on peut souvent renseigner plusieurs valeurs (par exemple si tu as plusieurs adresses email, tu renseigne plusieurs fois le champ mail.

          Ce dernier concept (les attributs multi-valués) est étranger aux SGBDR et permet souvent d'avoir un équivalent d'une distribution des données sur plusieurs tables dans un SGBD (par exemple, pour renseigner toutes les adresses emails d'une personne tu devrais avoir une table personne, et une table mail avec ID_personne et email. Ici tout est dans les infos de la personne). De plus tu peux ainsi tout récupérer en une seule requête de recherche.

          Une grosse différence est aussi le système d'authentification. Avec LDAP, toute entrée de l'annuaire peut servir d'identifiant, du moment qu'elle a un mot de passe (champ 'userPassword') ou quel est référencée dans le système d'authentification utilisé.
          Donc c'est naturellement que tout utilisateur peut s'authentifier, grace à l'opération LDAP du bind. Inutile d'aller chercher dans la base qui a ce login et qui a ce mot de passe.

          Euh... c'était quoi la question ? Ah, oui. Et bien, donne nous un exemple, on verra ce qu'on peut faire.
          LDAP ne peut dans la plupart des cas pas remplacer une base de donées relationnelle. Il est fait pour être complémentaire de celle-ci, et principalement :
          - stocker des informations (et non des relations)
          - assumer la fonction d'authentification
          - stocker les données d'autorisation (exemple : groupes, objets)

          Donc si tes relations servent à autoriser des personnes à accéder à des fonctionnalités ou à des données, c'est transcriptible sous LDAP. Pour le reste, il faut voir dans le détail. Tu peux toujours utiliser dans ta base des références vers les identifiants LDAP des utilisateurs, et mixer les deux dans ton appli PHP.

  • # Re: Partager les comptes utilisateurs entre différentes applications

    Posté par  (site web personnel) . Évalué à 1.

    Ah ca je veux bien t'aider :)
    et ca en interessera plus d'un
    pour la partie phpBB2 je peux un peu t'aider vu que j'ai fait ca
    pour mettre en relation le / de mon site web et le forum
    par contre fodrait synchroniser avec wikini
    (c'est pour http://sidenux.ath.cx(...) < /pub >)

  • # Re: Partager les comptes utilisateurs entre différentes applications

    Posté par  . Évalué à 2.

    Ca s'appelle du Single Sign-On.

    En libre y'a l'université de Yale qui a sorti CAS :
    http://www.yale.edu/tp/auth/(...)
    C'est du Java, ca a besoin d'un serveur J2EE, par exemple Tomcat.
    C'est assez lourd à mettre en oeuvre, mais ca marche.

  • # Re: Partager les comptes utilisateurs entre différentes applications

    Posté par  (site web personnel) . Évalué à 1.

    J'ai justement ce probleme en ce moment.
    J'ai besoin que les utilisateur de mon site puisse se connecter une fois, et que ca les logues a la fois dans egroupware et dans phpBB.
    Pour ca, je récupere le nom et le mot de passe du formulaire.

    J'ai repris la page de login de egroupware et j'ai viré tout ce qui n'était pas nécessaire. J'ai fait passer les nom et pass en GET dans ces pages pour que ca s'identifie.

    Ensuite, de la je fais une redirection http vers une page de login modifié de phpBB... meme principe.

    Et finalement, redirection http vers la page d'accueuil. Meme chose dans l'autre sens pour se déloguer.

  • # Re: Partager les comptes utilisateurs entre différentes applications

    Posté par  . Évalué à 1.

    Oh oh tu tombe à pic toi.

    Moi personnellement je voudrais un système de compte uniformisé et en même temps indépendant. Que quand tu te log sur le site A tu sois aussi loggué sur le site B (si tu t'y est inscrit bien sûr) et que tu ne puisse pas modifier tes infos utilisateur sur le site A ou le site B mais sur le site Y qui sert d'authentification pour les autres sites A et B.

    Donc en fait, le principe c'est qu'on a un site A et un site B et que pour logguer il fait une requête vers le site Y qui va dire si l'utilisateur a donné le bon mdp etc. Je suppose que chacun de ces sites est sur un serveur différent.

    Je me demande donc bien comment faire d'une manière sécurisée. J'ai déjà pensé dans un premier temps à de simples requêtes HTTP avec le mdp en clair mais ça va pas c'est pas bon ça. Maintenant je réfléchit plus à utiliser XML-RPC mais j'ai aucune idée de comment sécuriser ça.

    Sinon LDAP j'y connait rien et il parait que ça supporte pas du tout la charge.

    • [^] # Re: Partager les comptes utilisateurs entre différentes applications

      Posté par  . Évalué à 2.

      Donc en fait, le principe c'est qu'on a un site A et un site B et que pour logguer il fait une requête vers le site Y qui va dire si l'utilisateur a donné le bon mdp etc. Je suppose que chacun de ces sites est sur un serveur différent.

      La solution existe, elle s'appelle SAML, pour Simple Authentication Markup Language. Ce standard, basé sur XML, est promu par le consortium OASIS, et décrit dans différents documents ici :
      http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security(...)

      De nombreux cas d'utilisation sont décrits, le tiens en fait partie.

      Sinon tu as le système passport de MS :-) /o\

      Sinon LDAP j'y connait rien et il parait que ça supporte pas du tout la charge.

      Non tu n'y connais rien :)
      Le modèle de données LDAP, utilisé conjointement avec des index, est environ dix fois plus performant que le modèle de données relationnel pour les requêtes de recherche.

      Il est fait pour les données rarement mises à jour et souvent lues.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.