Le mer 28/01/2004 à 11:25, Rodolphe Quiedeville a écrit :
On Wed, 2004-01-28 at 10:59, address@hidden wrote:
On Wed, 28 Jan 2004, Rodolphe Quiedeville wrote:
Je suis avec passion la discussion sur l'auth de la partie publique
adherent. En fait j'ai une autre idée sur la question.
Pourquoi ne pas créer par achérent un login normal (dans llx_user) et
gérer ensuite les permissions pour que l'adherent puisse editer sa fiche
dans la partie commune. Cela simplifierait grandement les choses non ?
dans le fonctionnement de dolibarr, cela simplifierai grandement les
choses effectivement. Par contre cela implique de mettre en place les
droits d'acces (eh oui malgre la presence dans la gestion des
utilisateurs, cela n'a pas encore ete fait .. mea culpa ..) et des droits
d'acces assez fin (edition uniquement de sa fiche). Un autre detail (a
verifier) est qu'il y a besoin qu'on stocke le mdp de l'adherent en clair
(car necessaire pour creer des comptes sur d'autres outils tel que spip).
Je ne sais plus si les password dans la table llx_user sont en clair ou
pas.
Oui, dans llx_use ret llx_adherent ils sont en clair. Tant que l'on
utilise des schémas comme mod_auth_mysql c'est assez facile de basculer
à des mdp cryptés avec une requete sql (à mettre dans migration) et le
passage à On de la directive AuthMysqlCryptedPassword.
UPDATE llx_user SET pass=PASSWORD(pass);
Avec PEAR cela n'a pas l'air tellement plus dur mais l'activation du
cryptage se fait avec un paramètre non documenté, il est à none dans
l'appel du constructeur Pear::Auth().
Il va donc falloir desassembler :) le code PEAR poir voir a quoi et
comment ça sert.
en tout cas sur le long terme c'est une bonne idee. Yapluka coder si pas
d'autres objections :-)
Dans ce cas, les champs login et pass de la table llx_user ne sont plus
utiles, non?
Et a quoi sert la table llx_user_rights?
Parce que l'on risque d'en avoir besoin pour différencier les
utilisateurs:
-Droits restreints pour les adhérents à la lecture des infos publiques
et à l'édition de leur données personnelles.
-Droits en lecture sur tout pour les membres du bureau (ou du comité
d"administration)
-Droits complets en R/W pour le trésorier par exemple qui valide les
cotisations ou pour le secrétaire qui enregistre des inscriptions
Alors on va dans cette voir et je vais y contribuer aussi, pas
d'objection dans la salle ?
Non, c'est plus sain d'avoir les infos de login des utilisateurs dans
une seule table plutôt que deux. Je m'étais justement posé la question
du pourquoi de la chose en découvrant la structure de la base.
Juste une remarque: ça va être assez facile avec mod_auth_mysql car on
peut finement ajuster les droits pour chaque répertoire et différencier
les utilisateurs en groupes juste avec des directives apache. Par contre
avec pear il va falloir tout coder pour arriver au même résultat. Si
l'un de vous a envie d'ajouter la fonctionnalité au module PEAR::Auth,
c'est le moment de vous lancer parce que je pense que ça va valoir le
coup :-/