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 :

  • cookies pour une connexion persistante

  • logique de réinitialisation de mot de passe

  • stockage sécurisé des mots de passe

  • déconnexion

  • UIs 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, alors assurez-vous de vérifier cela en premier.

Gestionnaires d’accès

Les fonctions de gardien Gatekeeper vous permettent de gérer l’exécution du code en appliquant les règles de contrôle d’accès.

Redirige un utilisateur vers la page d’accueil s’il n’est pas connecté avec elgg_gatekeeper() :

elgg_gatekeeper();

echo "Information for logged-in users only";

Note

Dans Elgg 1.8 et en dessous de cette fonction a été appelé gatekeeper()

Redirige un utilisateur vers la page d’accueil à moins qu’il ne soit un administrateur avec elgg_admin_gatekeeper() :

elgg_admin_gatekeeper();

echo "Information for admins only";

Note

Dans Elgg 1.8 et en dessous, cette fonction était appelé admin_gatekeeper()

Prévient les attaques CSRF avec action_gatekeeper().

action_gatekeeper();

// Mutate some state in the database on behalf of the logged in user...

Cette fonction devrait être utilisée dans les Formulaires + Actions avant Elgg 1.8.

Note

À partir de la version 1.8 de Elgg, cette fonction est appelée pour toutes les actions enregistrées. Il n’est plus nécessaire d’appeler cette fonction dans vos propres actions. Si vous souhaitez protéger d’autres pages avec des jetons d’action, vous pouvez appeler cette fonction.

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_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 préféré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 le fichier start.php du du plugin, et de l’enregistrer avec le module PAM afin qu’il soit 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 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 init du plugin, par exemple :

function your_plugin_init() {
   // Register the authentication handler
   register_pam_handler('your_plugin_auth_handler');
}

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

// Add the plugin's init function to the system's init event
elgg_register_elgg_event_handler('init', 'system', 'your_plugin_init');

Importance

Par défaut, un module d’authentification est enregistré avec une importance de sufficient (suffisant).

Dans une liste de modules d’authentification ; si n’importe lequel de ces modules marqué sufficient renvoie true, pam_authenticate() renverra également true. L’exception à cela est lorsqu’un module d’authentification est enregistré avec une importance de required. Tous les modules requis doivent renvoyer true pour que pam_authenticate() renvoie true, indépendamment du fait que tous les modules suffisants retournent 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 (nom d’utilisateur et 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.