Besoin
Le besoin serait de pouvoir choisir le système d'identification de
WikiNi.
WikiNi serait livré avec son propre système d'identification par défaut, mais il pourrait, sous certaines conditions, utiliser d'autres systèmes d'identification. Les applications sont les suivantes :
- intégration de WikiNi à d'autres applications
- utilisation d'outils d'identification spécialisés permettant de s'identifier une seule fois pour utiliser un ensemble d'application (LDAP par exemple)
Ailleurs
Discussions
Je reproduit ci-dessous les besoins formulés initialement par
JeanYves et
EddyFayet?. --
CharlesNepote
Rendre modulaire la gestion des utilisateurs
Dans le même esprit, pour faciliter l'intégration avec d'autres softs, exemple une classe de gestion d'utilisateur dans un fichier include qui serait remplaçable.
--
JeanYves
- C'est en effet possible, mais cela impose pas mal de changement. On peut définir 2 types de changement :
- Supprimer les fonctions de gestion des utilisateurs dans la classe wiki et remplacer les appels à ces fonctions par des appels aux méthodes de la classe gérant les utilisateurs. C'est certainement le code le plus propre, mais aussi un gros travaille car il faut chercher tous les appels dans les actions et handlers.
- Garder les fonctions de gestion des utilisateurs mais les recoder pour qu'elles appelent les méthodes de la classe de gestion des utilisateurs. C'est surement le plus rapide à faire et il y a très peu d'impact sur le code existant.
- --GarfieldFr
- J'opterais plus pour la seconde solution, vu que je suis assez pour que tout passe par le noyau (qui utilise des modules derrière). Le code est alors plus simple (pas besoin de se souvenir de n classes par module), plus propre (tout passe par un point central de gestion), ce qui n'empêche pas d'être hautement modulaire (mais c'est caché par le noyau). À comparer au modèle de Linux... ;-) -- ProgFou.
- Dans les 2 cas, tous passe par le noyau, c'est la classe wiki qui crée l'objet $user et qui l'utilise. Simplement dans un cas il y a beaucoup de changement à faire, et dans l'autre assez peu de changement mais un code peut être moins élégant. --GarfieldFr
Si vous pouviez prendre un exemple pour les deux solutions parce que je ne comprends pas tout là... --
CharlesNepote
- Voila en détail les 2 solutions possible :
- Une classe user qui gere les utilisateurs de Wikini. La classe Wiki crée dans son constructeur (la méthode Wiki() ) une instance $user de cette classe. Partout ou des appels au anciennes fonctions de gestion des utilisateur sont fait il faut remplace par un code du type : $this->user->nomDeMethode(...). On a donc beaucoup de remplacements à faire, dans le fichier wakka.php mais aussi dans les actions et les handlers. Par exemple, tous les appels du genre : $this->GetUserName?() devront être remplacé par $this->user->GetUserName?().
- Une classe user qui gere les utilisateurs de Wikini. La classe Wiki crée dans son constructeur (la méthode Wiki() ) une instance $user de cette classe. Ensuite on remplace le code des fonctions de gestion des utilisateurs par un appel à une méthode de l'instance $user. Par exemple pour la méthode wiki::GetUserName?() on aura
- function GetUserName() { if ($user = $this->GetUser?()) $name = $user["name"]; else if (!$name = gethostbyaddr($_SERVER["REMOTE_ADDR"])) $name = $_SERVER["REMOTE_ADDR"]; return $name; }
- function GetUserName() {return $this->user->GetUserName?() }
C'est plus clair comme ca ?
--
GarfieldFr
Gestion des comptes utilisateurs par LDAP
Une identification des utilisateurs par un annuaire LDAP serait très intéressant.
idem pour moi, j'ai utilisé wikini dans mon intranet d'entreprise (basé sur l'ad de windows 2000) et j'aimerai bien que l'identification se fasse également via le protocole ldap. J'ai regardé vite fait mais cho cho :/ --
EddyFayet?
Le code actuel concerné
Rappelons ici le code gérant les utilisateurs.
<?php
// USERS
function LoadUser($name, $password = 0) { return $this->LoadSingle("select * from ".$this->config["table_prefix"]."users where name = '".mysql_escape_string($name)."' ".($password === 0 ? "" : "and password = '".mysql_escape_string($password)."'")." limit 1"); }
function LoadUsers() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."users order by name"); }
function GetUserName() { if ($user = $this->GetUser()) $name = $user["name"]; else if (!$name = gethostbyaddr($_SERVER["REMOTE_ADDR"])) $name = $_SERVER["REMOTE_ADDR"]; return $name; }
function UserName() { /* deprecated! */ return $this->GetUserName(); }
function GetUser() { return (isset($_SESSION["user"]) ? $_SESSION["user"] : '');}
function SetUser($user, $remember=0) { $_SESSION["user"] = $user; $this->SetPersistentCookie("name", $user["name"], $remember); $this->SetPersistentCookie("password", $user["password"], $remember); $this->SetPersistentCookie("remember", $remember, $remember); }
function LogoutUser() { $_SESSION["user"] = ""; $this->DeleteCookie("name"); $this->DeleteCookie("password"); }
function UserWantsComments() { if (!$user = $this->GetUser()) return false; return ($user["show_comments"] == "Y"); }
function GetParameter($parameter) { return (isset($this->parameter[$parameter]) ? $this->parameter[$parameter] :''); }
?>
Authentifier les utilisateurs à partir d'une BD MySQL externe
Une solution est proposée à l'URL
http://contrib.africacomputing.org/wakka.php?wiki=AuthentificationExterneWikini
Elle consiste à :
- remplacer dans wakka.php la méthode LoadUser afin de chercher le login et le mot de passe dans une base de données MySQL autre que celle utilisée par défaut par Wikini et construire un utilisateur correspondant à mot Wiki valide et unique;
- ajouter des variables de configuration dans wakka.config.php (pour ne pas aller tapper dans le code de wakka.php pour spécifier base, table et champs utilisés);
- suprrimer dans l'actions usersettings la partie permettant de modifier ses paramètres utilisateurs (pour conserver la maitrise des modifications des profils par une application tierce).
--
PhilippeDrouot
- Pour l'authentification, ok, quoi que ce ne soit pas la méthode prévue : a priori nous passerons par la définition d'une classe user qui sera externe (donc remplaçable à souhait) et appelée par le coeur de WikiNi. Cela évitera aussi, entre autre, le mélange des options de WikiNi avec celles du module d'authentification.
- Sur le fait de supprimer des paramètres utilisateurs, c'est clairement une dégradation des fonctionnalités de WikiNi ! Pourquoi ne pas ajouter une table wikini_users, voir plus simplement des colonnes, à la base utilisateur de l'application tierce ?
- -- ProgFou
- La contribution proposée a été réalisée pour répondre à un besoin spécifique et en particulier, nous ne pouvions intervenir sur la structure de la base de l'application tierce : c'est pour cette raison que les paramètres utilisateurs sont définis pour l'ensemble des utilisateurs et ne font pas l'objet de l'ajout d'une table ou de colonnes (Cela explique également pourquoi les mots wiki correspondant aux utilisateurs sont construits à partir de champs existants tels que Prénom, Nom, Identifiant unique). -- PhilippeDrouot
Première tentative
J'ai commencé à regarder de près à ce problème car il m'intéresse (pour remettre au propre la contrib Spikini).
J'ai opté pour les points suivants :
- une classe User contenant les méthodes getUser, getName, loadUser ... mais aussi les setCookie and co qui ne sont utilisés que par les méthodes précédentes.
- une classe Bdd qui rassemble toutes les méthodes d'accès à la bdd (query, loadSingle mais aussi connect, fetch_assoc ...). C'est plus pratique car la classe User «par défaut» à besoin d'accéder à la bdd mais n'a pas besoin de la classe Wiki, c'est donc plus propre d'externaliser ce point. De plus, ça permettrait de passer en autre chose assez facilement, ou simplement de choisir facilement entre connect et pconnect selon l'hébergement.
- tous les appels aux $wiki->LoadUser et autres deviennent des $wiki->user->loadUser().
J'ai maintenant une
version assez stabilisée, mais qui demande à être testée.
Comme j'ai tiré de fil de pas mal de trucs, j'arrive à une modif assez profonde du code.
Le résultat est visible
ici, et les modifs sont détaillées
.