Propositions d'évolution de l'ActionUserSettings

Etude de la version actuelle

Fonctionnalités

La version actuelle de l'ActionUserSettings permet de :

• Créer un utilisateur sans vérification de l'adresse de courriel.
• Se connecter à WikiNi.
• Modifier les paramétres de l'utilisateur.
• Changer le mot de passe de l'utilisateur (Nicephore17 est volontaire pour le codage de ça). désolé mais c'est déjà dans le script ;o), je suppose que tu voulais parler de l'envoi d'un nouveau mot de passe en cas de perte -- OlivierB Exact -- Nicephore17

Actuellement même si l'adresse de courriel est demandée, elle n'est pas utilisée dans WikiNi.

Table SQL

La table users est constituée des colonnes suivantes :

• name : NomWiki de l'utilisateur.
• password : mot de passe de l'utilisateur codé avec la fonction md5
• email : adresse de courriel.
• motto : Devise de l'utilisateur (utilité ?).
• revisioncount : Nombre maximum de versions affichées dans les historiques des pages.
• changecount : nombre maximum de commentaires affichés sur les pages.
• doubleclickedit : Indicateur pour la fonction édition d'une page en double cliquant dessus.
• signuptime : date d'inscription (cf actions/usersettings.php)
• show_comments : Indicateur d'affichage par défaut des commentaires.

Décomposition de l'ActionUserSettings

L'ActionUserSettings est constituée par plusieurs formulaires HTML dont le fonctionnement est conditionné par la variable action (pseudo code) :

• Si action n'existe pas on l'initialise à vide
• Si action='logout' : Déconnexion de l'utilisateur (l'utilisateur connecté devient un utilisateur anonyme).
• Sinon si un utilisateur est connecté :
  • Si action='update' : Mise à jour des paramétres de l'utilisateur connecté (il faut que l'utilisateur soit connecté bien sur).
  • Si action='changepass' : Changement du mot de passe après vérification de l'ancien.
  • On affiche le formulaire pour l'update et le formulaire changepass.
• Sinon
  • Si action='login' : Connexion de l'utilisateur.
    • Si l'utilisateur existe, vérifier son mot de passe puis le connecter et réafficher la page
    • Si l'utilisateur n'existe pas, le créer, le connecter et réafficher la page
  • Affichage du formulaire pour le login.

---

Proposition d'évolution de l'action

Discussion préliminaire

Pour la création des nouveaux utilisateurs, l'action doit pouvoir (paramétrable) :

• Fonctionner comme la version actuelle (0.4.3).
• Envoyer un mail aux administrateurs (au moins 1) pour validation de l'utilisateur.
  • Un champ motivation pourrait être intéressant pour permettre aux administrateurs de juger de la pertinence de l'inscription. Cette méthode d'inscription va de paire avec la restriction des droits d'écriture sur les pages aux seuls utilisateurs connectés.
  • Une méthode serait d'envoyer par mail un mot de passe d'activation (différent de son mot de passe) que l'utilisateur pourrait saisir sur la page de l'ActionUserSettings. Cette méthode présente l'avantage que tout serait géré dans l'ActionUserSettings sans devoir mettre en oeuvre une usine à gaz.
  • Une autre méthode pourrait être de créer un lien dans le mail vers l'ActionUserSettings avec comme paramétre une chaîne codée. L'activation de ce lien aura pour effet d'activer l'utilisateur.
• Envoyer un mail de confirmation à l'utilisateur en lui demandant de faire une action particulière pour valider son inscription.
  • Le plus simple serait sûrement de générer aléatoirement un mot de passe et de l'envoyer par mail avec une notice sur la manière de le changer. De même, on pourrait forcer un changement + envoi de mot de passe à chaque changement de mail. Le problème étant la nécessité de la fonction mail(), je ne sais pas si tous y ont accès (Nicephore17)
    • C'est une solution. Cette fonctionnalité ne peut fonctionner qu'avec la fonction mail(). Ceux qui n'en dispose pas ne peuvent bien sur pas l'utiliser. Dans phpBB il me semble que l'on peut paramétrer soit la fonction mail soit l'envoi par un serveur SMTP. Pour l'instant restons simple en utilisant la fonction mail(). -- OlivierB
    • En réalité, puisque WikiNi est modulaire on peut envisager deux ActionUserSettings: 1) celle utilisée actuellement pour ceux qui n'ont pas accés à mail() et 2) celle avec des option supplémentaires (mail mot de passe and co) pour ceux qui peuvent l'utiliser. C'est le meilleur moyen de ne pénaliser personne sachant que, à terme, il serait probablement possible de recoder 1) avec l'utilisation d'un SMTP. -- Nicephore17
• Interdire la création de nouveaux utilisateurs (fonctionnement en weblog par exemple).

Fonctions supplémentaires :

• Fonction de renvoi d'un nouveau mot de passe en cas de perte. La question est de savoir s'il faut oui ou non écraser l'ancien mot de passe au cas où la demande ne serait pas faite par l'utilisateur.
• Je propose aussi un champ "accepter l'être contacté par mail" qui en fonction de Wiki pourrait être utilisé avec des fonction d'envoi de mail ou de liste de distribution. -- Nicephore17.

L'ajout de ces nouvelles fonctionnalités nécessiteront la modification de la table SQL users.

Mise en oeuvre

Variables de configuration

Ajout de deux variables de configuration :

• La variable create_user_mode :
  • CREATE_USER_DEFAULT_MODE : mode de fonctionnement par défaut .
    Fonctionnement comme dans la version actuelle (0.4.3) c'est à dire sans vérification de mail.
  • CREATE_USER_VALIDATION_BY_ADMIN : mode de fonction avec demande par mail de validation de la création d'un nouvel utilisateur aux administrateurs.
  • CREATE_USER_VALIDATION_BY_MAIL : mode de fonctionnement avec demande par mail de validation à l'adresse fournie par l'utilisateur.
  • CREATE_USER_FORBIDDEN : mode de fonctionnement avec interdiction de créer de nouveaux utilisateurs
• La variable create_user_admin_mails : contient la liste des adresses mails des administrateurs pour la validation de la création des utilisateurs.
  Exemple dans $WakkaConfig : "create_user_admin_mails" => "mon.mail@mon.domaine, ma.liste@mon.domaine",

Dans un premier temps, mettre ces variables dans $WakkaConfig et y accéder par une nouvelle méthode de l'objet wiki (voir InterfaceDAdministrationWikiNi discussion sur une nouvelle méthode appelée GetFunctionnalConfigValue - nom non définitif -). Tant que cette méthode n'existe pas utiliser GetConfigValue.

Discussion sur les méthodes de validation

Possibilités :

• Formulaire dans lequel il faudrait indiquer la clé de validation.
• Lien direct avec la clé en paramétre
  Exemple :
  http://www.wikini.net/wakka.php?wiki=ParametresUtilisateur&action=uservalidation&key=fagdd4Fske5djejecg5478DFTG

Ma préférence va pour la deuxième solution.

Il existe deja un systeme comparable sur Wiki5, un de WikiNi. --UnAnonyme

• J'ai regardé sur Wiki5 mais ce n'est pas tout à fait la même chose : Si j'ai bien compris il y a une variable cle dans le fichier de config et lors de l'inscription il faut saisir cette clé pour pouvoir créer l'utilisateur. C'est une façon d'interdire à n'importe qui de créer un nouvel utilisateur. Lorsque je parle de clé, je parle d'une clé générée aléatoirement pour la création d'un seul utilisateur. A chaque création la clé sera différente. -- OlivierB

Discussion sur la fonction de création d'un nouveau mot de passe en cas de perte

Possibilités :

• Création d'un nouveau mot de passe et envoi par mail
  Question faut-il garder l'ancien mot de passe en attendant que le nouveau soit activé ?
  Il faut demander au minimum le nom d'utilisateur et l'adresse mail pour vérifier avec la base de données avant d'envoyer un nouveau mot de passe.
• Envoyer un lien avec un clé (comme la validation) permettant d'accéder à une page de changement de mot de passe.
  Exemple :
  http://www.wikini.net/wakka.php?wiki=ParametresUtilisateur&action=lostpass&key=fagdd4Fske5djejecg5478DFTG

Décomposition de la nouvelle ActionUserSettings

En cours de jardinage ;o) (il faut encore y inclure la validation par l'utilisateur ou l'administrateur et la création d'un nouveau mot de passe)

Pseudo code :

• Si action n'existe pas on l'initialise à vide
• Si action='logout' : Déconnexion de l'utilisateur (l'utilisateur connecté devient un utilisateur anonyme).
• Sinon si action='lostpass' : Envoyer un mail avec un nouveau mot de passe à l'adresse de l'utilisateur.
• Sinon si action='uservalidation' : en cours ... à détailler
• Sinon si un utilisateur est connecté :
  • Si action='update' : Mise à jour des paramétres de l'utilisateur connecté (il faut que l'utilisateur soit connecté bien sur).
  • Si action='changepass' : Changement du mot de passe après vérification de l'ancien.
  • On affiche le formulaire pour l'update et le formulaire changepass.
• Sinon
  • Si action='login' : Connexion de l'utilisateur.
    • Si l'utilisateur existe, vérifier son mot de passe et que son status est validé puis le connecter.
      • Si le status de l'utilisateur est validé alors
        • en cours ... voir comment intégrer le test quand l'utilisateur a perdu son mot de passe
      • Sinon le status de l'utilisateur n'est pas validé : Message d'erreur indiquant que l'utilisateur ne peux se connecter tant que celui-ci n'a pas été validé.
    • Sinon l'utilisateur n'existe pas alors
      • Cas où create_user_mode = CREATE_USER_DEFAULT_MODE : Créer l'utilisateur avec le status validé, le connecter et réafficher la page.
      • Cas où create_user_mode = CREATE_USER_VALIDATION_BY_ADMIN : Créer l'utilisateur avec le status non validé, envoyer un mail aux administrateurs. à suivre ...
      • Cas où create_user_mode = CREATE_USER_VALIDATION_BY_MAIL : Créer l'utilisateur avec le status non validé, créer une clé de validation, envoyer un mail à l'utilisateur. à suivre ...
      • Autres cas : message indiquant que la création d'un nouvel utilisateur est impossible (cas CREATE_USER_FORBIDDEN).
  • Affichage du formulaire pour le login, affichage du formulaire pour la perte du mot de passe (action='lostpass').

Pour les options de configuration, il est préférable d'utiliser des constates (du genre DEFAULT_MODE etc.) entières (il suffit que chaque constante ait une valeur entière différente, et cette valeur pourrait même changer sans affecter tout le programme) Utiliser des chaines ne présente, à mon sens, aucun intérêt, au contraire même (fautes de frappe, plus d'utilisation de mémoire etc.)
Pour la clef de validation le mieux c'est d'utiliser uniqid()
Je pense qu'il va être inévitable d'avoir à créer plusieurs champs dans la table user

• actif/inactif
• clef d'activation
• nouveau mot de passe

(il y a peut-être moyen de combiner ces champs, mais ça risque de compliquer tout...)
-- LordFarquaad

• Tu as tout as fait raison pour les constantes (erreur de ma part), je corrige. merci pour uniqid(), je ne connaissais pas.
• Pour la tabel user je rajouterai en plus une colonne motivation pour le cas où les admin voudraient filtrer les inscriptions. Il est toujours intéressant de savoir pourquoi un visiteur veut s'inscrire.
• -- OlivierB

Nouvelle Table users

• name : NomWiki de l'utilisateur.
• password : mot de passe de l'utilisateur codé avec la fonction md5
• email : adresse de courriel.
• motto : Devise de l'utilisateur (utilité ? faut-il la conserver ?).
• revisioncount : Nombre maximum de versions affichées dans les historiques des pages.
• changecount : nombre maximum de commentaires affichés sur les pages.
• doubleclickedit : Indicateur pour la fonction édition d'une page en double cliquant dessus.
• signuptime : date d'inscription
• show_comments : Indicateur d'affichage par défaut des commentaires.
• active : indicateur permettant de savoir si l'utilisateur est actif (Y : yes, N : no, W : wait - en attente de validation -).
• actkey : clé d'activation
• une colonne pour la gestion de la perte du mot de passe ?
• motivations : motivation de l'utilisateur lors de son inscription.
• acceptmail : l'utilisateur accepte d'être contacté par mail (à utiliser dans des actions comme ActionMailToUser ou DiscussionsActionEcrivezMoi)

Pour activeuser, je trouve que ce n'est pas tout à fait clair, je préfèrerais quelque chose du genre user_is_active ou alors comme dans PhpBB2: user_active... On peut imiter aussi pour le reste: user_actkey et user_newpasswd. A la limite ça permet même de simplifier la fusion des deux (je pense qu'il y a des gens que cela intéresse...) [Pour ma part j'utilise active ENUM('Y','N','W'), 'W' correspondant à un compte en attente de validation (wait). -- ProgFou]
Ah oui sinon, pour le champ signuptime auquel personne n'a jamais trouvé d'utilité:
Comme son nom l'indique, j'imagine qu'il s'agit d'un compteur totalisant le temps passé à être connecté à WikiNi, c'est à dire la somme des durées de toutes les sessions. [Non, c'est plus simplement la date d'inscription de l'utilisateur. Cf actions/usersettings.php. -- ProgFou.] Seulement voilà, problème: WikiNi laisse la gestion des session se faire avec les fonctions existantes de PhP, c'est à dire via des fichiers temporaires auxquels il est difficile (impossible ? sinon c'est une faille potencielle en fait...) d'accéder. Il est donc impossible de savoir le temps que passent les utilisateurs à être connectés. Pour le faire il faudrait que ce soit géré via la base de données (notez que c'est très facile à mettre en oeuvre, et d'ailleurs je prévois de le faire pour pouver créer une action du style "WhoIsOnline") -- LordFarquaad

Est ce que dans le cadre des FeuillesDeStyleMultiples on ne devrait pas aussi rajouter une colonne indiquant quel style l'utilisateur veux utiliser (a choisir dans une liste de style disponible) ?? Cela grossi la table, mais évite le système de cookies et permet d'avoir le même style automatiquement malgré une utilisation multiposte... --BasHaq

• Ah oui ce serait pas mal en effet. Il faudrait juste voir si cela ne poserait pas de problème, exemple: si on supprime un style... -- LordFarquaad

Contrepoint
Pour ma part, je pense que s'il faut toucher à cette table c'est pour la dégraisser et non pour l'alourdir. Ca me rapelle l'histoire de petits CMS très sympa qui ont tellement grossis avec le temps qu'ils sont devenus des usines à gaz... Dans tout ce que vous proposez, beaucoup de champs ne seront utiles qu'à un utilisateurs sur 10 (ce qui est déjà un peu le cas). Je ne dis pas qu'ils n'ont pas d'intérêt, mais pourquoi ceux-là plutôt que d'autres ? Parce que des idées de métadonnées sur les utilisateurs je peux vous en fournir des wagons qui seront parfaitement défendables (il n'y a qu'à regarder les dizaines d'options que propose MediaWiki? (qui fait tourner wikipédia)) : timezone, barre d'édition, placement du menu, taille de la fenêtre d'édition, etc. Je ne vois aucune raison pour privilégier telles propriétés plutôt que d'autres. Les trois champs qui me paraissent utiles sont :

• name : NomWiki de l'utilisateur.
• password : mot de passe de l'utilisateur codé avec la fonction md5
• email : adresse de courriel.

Seuls ces trois champs seront utiles à tous les utilisateurs. Le reste pourrait tenir, avec une requête SQL de plus, dans la table des triplets que je défend, permettant ainsi :

• de multiplier à l'infini le nombre de paramètres
• d'éviter de conserver des données qui ne concernent pas m'utilisateur : exemple : 99% des utilisateurs ne changent rien aux actuels champs revisioncount, changecount, doubleclickedit, show_comments, etc. Une valeur par défaut suffirait et quand, par hasard, un utilisateur souhaiterai la changer, elle serait alors écrite dans la table des triplets.

Qu'en pensez-vous ?
-- CharlesNepote
Je suis pour !
-- ErwanPigneul

J'en pense qu'il va falloir coder une action pour voter tout ça...
-- Nicephore17

---

---