Comment un module doit-il modifier la valeur du global $user
, exécuter son propre code et restaurer la valeur d'origine de $user
sans entraîner la déconnexion de l'utilisateur actuel en cas d'erreur?
Comment un module doit-il modifier la valeur du global $user
, exécuter son propre code et restaurer la valeur d'origine de $user
sans entraîner la déconnexion de l'utilisateur actuel en cas d'erreur?
Réponses:
La fonction drupal_cron_run () donne un exemple parfait pour cela, car elle change l'utilisateur actuel en anonyme chaque fois que cron est exécuté, puis revient en arrière une fois terminé.
// Prevent session information from being saved while doing funky stuff.
$original_session_state = drupal_save_session();
drupal_save_session(FALSE);
// Force the current user to anonymous to ensure consistent permissions on
// funky stuff runs.
$original_user = $GLOBALS['user'];
$GLOBALS['user'] = drupal_anonymous_user(); // Or use user_load() for a non-anonymous user.
// Do funky stuff here...
// Restore the user.
$GLOBALS['user'] = $original_user;
drupal_save_session($original_session_state);
$GLOBALS
ou simplement dans une autre variable pour la sauvegarde) et basculer vers n'importe quel utilisateur en les chargeant avec user_load()
. Ce qui vous permet de faire des choses horribles comme se faire passer pour un utilisateur spécifique configuré avec des autorisations spécifiques pour effectuer un processus spécifique. Le principe est le même.