Authentification

Elgg fournit d’emblée tout ce qui est nécessaire pour authentifier les utilisateurs via le nom d’utilisateur/l’e-mail et le mot de passe, y compris :

cookie permanent pour une connexion persistante

logique de réinitialisation de mot de passe

stockage sécurisé des mots de passe

déconnexion

Interfaces utilisateurs - UI - pour accomplir tout ce qui précède

Il ne vous reste plus en tant que développeur qu’à utiliser les fonctions d’authentification intégrées pour sécuriser vos pages et vos actions.

Travailler avec l’utilisateur connecté

Vérifiez si l’utilisateur actuel est connecté avec elgg_is_logged_in() :

if (elgg_is_logged_in()) {
  // do something just for logged-in users
}

Vérifiez si l’utilisateur actuel est un administrateur avec elgg_is_admin_logged_in() :

if (elgg_is_admin_logged_in()) {
  // do something just for admins
}

Récupérez l’utilisateur actuellement connecté avec elgg_get_logged_in_user_entity() :

$user = elgg_get_logged_in_user_entity();

L’objet retourné est un ElggUser de sorte que vous pouvez utiliser toutes les méthodes et propriétés de cette classe pour accéder à des informations sur l’utilisateur. Si l’utilisateur n’est pas connecté, cela vous renvoie null, aussi assurez-vous de vérifier cela en premier.

Gestionnaires d’accès - gatekeepers

Les fonctions de gestion d’accès « gatekeeper » vous permettent de gérer l’exécution du code en appliquant des règles de contrôle d’accès.

Redirigez vers la page d’accueil un utilisateur qui n’est pas connecté avec elgg_gatekeeper() :

elgg_gatekeeper();

echo "Information for logged-in users only";

Redirigez vers la page d’accueil un utilisateur, sauf s’il s’agit d’un administrateur avec elgg_admin_gatekeeper() :

elgg_admin_gatekeeper();

echo "Information for admins only";

Modules d’authentification enfichables - Pluggable Authentication Modules

Elgg est compatible avec des modules d’authentification enfichables (PAM = Pluggable Authentication Modules), qui vous permettent d’écrire vos propres gestionnaires d’authentification. A chaque fois qu’une requête a besoin d’être authentifiée, le système va appeler elgg_pam_authenticate() qui va vérifier tous les gestionnaires de PAM enregistrés jusqu’à-ce que l’un d’entre eux renvoie un succès.

L’approche privilégiée est de créer un plugin Elgg séparé qui aura une tâche simple : traiter une demande d’authentification. Il s’agit de configurer un gestionnaire d’authentification dans la classe Bootstrap, et de l’enregistrer auprès du module PAM pour traité chaque fois que le système doit authentifier une requête.

Le gestionnaire d’authentification est une fonction qui prend un seul paramètre. L’enregistrement du gestionnaire se fait par elgg_register_pam_handler() qui prend le nom du gestionnaire d’authentification, l’importance et la politique de validité comme paramètres. Il est conseillé d’enregistrer le gestionnaire dans la fonction d’initialisation du plugin, par exemple :

// classes/Your/Plugin/Bootstrap.php

function init() {
   // Register the authentication handler
   elgg_register_pam_handler('your_plugin_auth_handler');
}

// your_plugin/lib/functions.php

function your_plugin_auth_handler($credentials) {
   // do things ...
}

Importance

Par défaut, un module d’authentification est enregistré avec une importance suffisante.

Dans une liste de modules d’authentification ; si n’importe lequel des modules marqués sufficient renvoie true, elgg_pam_authenticate() renverra également true. L’exception à cela est lorsqu’un module d’authentification est enregistré avec une importance marquée required. Tous ces modules requis doivent renvoyer true pour que elgg_pam_authenticate() renvoie true, indépendamment du fait que les modules suffisants renvoient true.

Informations d’identification transmises

Le format des informations d’identification transmises au gestionnaire peut varier en fonction de la demande d’origine. Par exemple, une connexion classique via le formulaire de connexion créera un tableau indexé, avec les clefs username et password. Si une demande a été faite par exemple via XML-RPC, les informations d’identification seront définies dans l’entête HTTP, de sorte que dans ce cas rien ne sera transmis au gestionnaire d’authentification, et que le gestionnaire devra effectuer ses propres étapes pour authentifier la demande.

Valeur de retour

Le gestionnaire d’authentification doit renvoyer un booléen, indiquant si la demande peut être authentifiée ou non. Une mise en garde est que dans le cas d’une connexion utilisateur classique où les informations d’identification sont disponibles sous la forme d’un nom d’utilisateur et d’un mot de passe, l’utilisateur sera connecté. Dans le cas de l’exemple XML-RPC, le gestionnaire d’authentification devra effectuer cette étape lui-même puisque le reste du système n’aura aucune idée des formats possibles des informations d’authentification passées ni de leur contenu. La connexion d’un utilisateur est assez simple et se fait par login(), qui s’attend à recevoir un objet ElggUser.