Le module de règles ne capte pas l'événement (externe) "Connexion utilisateur"?

Question

Dans mon installation, les utilisateurs se connectent avec Shibboleth [1], mais la règle [2] que j'ai configurée pour être exécutée sur l'événement "Utilisateur connecté" n'est pas exécutée. En revanche, lorsque je me connecte en tant qu'administrateur par le biais de Drupal normal, la règle est exécutée. Cela signifie-t-il que l'événement de connexion externe n'est pas du tout géré?

Y at-il un moyen de surmonter cela?

[1] http://drupal.org/project/shib_auth

[2] http://drupal.org/project/rules

Answer 1

Cela semble être a bug of the Shibboleth module, donc la connexion 'événement' n'est en effet pas soulevée par elle (en termes de Drupal, elle n'invoque pas hook_user() avec $op = 'login').

Looking at the Shibboleth code, la connexion semble se produire dans sa mise en œuvre hook_init():

/** 
* Create a new user based on informations from the Shibboleth handler if it's necessary or log in. 
*/ 
function shib_auth_init() { 
    global $user; 

    $unameVar = variable_get('shib_auth_username_variable', 'REMOTE_USER'); 
    $umailVar = variable_get('shib_auth_username_email', 'HTTP_SHIB_MAIL'); 

    // If 
    // - The user isn't logged in 
    // - There is Shibboleth authentication in the background 
    // - The settings are fine and there has been a valid username setted up 
    // - The settings are fine and there has been a valid user email address setted up 
    if (!$user->uid && $_SERVER['HTTP_SHIB_IDENTITY_PROVIDER']) { 
    if ($_SERVER[$unameVar] && $_SERVER[$umailVar]) { 
     user_external_login_register($_SERVER[$unameVar], "shib_auth"); 
    } 
    else { 
     drupal_set_message(t("Username or e-mail address is missing. Maybe the Shibboleth configuration is not perfect."),"error"); 
    } 
    } 
    if ($user->uid && $_SERVER['HTTP_SHIB_IDENTITY_PROVIDER']) { 
    $account = user_save($user,array('mail' => $_SERVER[$umailVar])); 
    // Terminate if an error occured during user_save(). 
    if (!$account) { 
     drupal_set_message(t("Error saving user account."), 'error'); 
     return; 
    } 
    $user = $account; 
    } 
} // function shib_auth_init() 

Vous aurez besoin de patcher et et veiller à ce que user_module_invoke() est appelé. La méthode standard pour le faire serait d'appeler user_authenticate_finalize() après une connexion réussie (qui appellera à son tour user_module_invoke()), de sorte que vous souhaitez ajouter qu'après l'appel user_external_login_register():

[...] 
    if ($_SERVER[$unameVar] && $_SERVER[$umailVar]) { 
     user_external_login_register($_SERVER[$unameVar], "shib_auth"); 
     // Do we have a logged in user now? 
     if ($user->uid) { 
     // Yes, ensure watchdog logging and proper invocation of hook_user 
     // NOTE: We pass an empty array, as no form submit was involved here, 
     // but we could also pass an array with 'unameVar' and 'umailVar', 
     // as they would be the closest substitute. 
     user_authenticate_finalize(array()); 
     } 
    } 
    [...] 

REMARQUE: code non testé, méfiez-vous de fautes de frappe et autres oublis stupides;)

Si vous finissez par le faire, vous pourriez vouloir le soumettre comme un correctif au rapport de bug lié ci-dessus. (seulement si cela fonctionne, évidemment;)

Answer 2

L'ordre dans lequel les modules Drupal charge est très important dans ces cas. Vous devrez définir des règles afin qu'elles soient chargées après votre module d'authentification. Par exemple, avec ldap_integration

mysql> UPDATE system SET weight=20 WHERE name="rules"; 
mysql> UPDATE system SET weight=20 WHERE name="rules_forms"; 
mysql> UPDATE system SET weight=0 WHERE name="ldapauth"; 

« 20 » est un nombre arbitraire qui est plus grand que quel que soit votre module d'authentification est.

Answer 3

Drupal exécute hooks, ce qui signifie que les modules ont la possibilité d'exécuter un morceau de code. Par exemple. lors de la connexion, un hook_user est appelé.

Trop souvent, les modules appellent un drupal_goto() à l'intérieur de ces crochets. Cela va sévèrement casser. Drupal_goto va tout tuer, envoyer un en-tête de redirection, puis mourir l'application. Aucun autre hook ne sera exécuté. Les crochets ne devraient jamais appeler drupal_goto(), die() ou d'autres fonctions destructrices. Mais puisque rien n'empêche les gens de violer cette règle, les gens (modules) vont la casser. Form_alter ne doit jamais invoquer des goto, des matrices et ainsi de suite, pour la même raison. Vous pouvez trouver n'importe quels goto "illégaux" en installant le module devel et en basculant le paramètre "montrer les redirections", vous verrez si par ex. sibbletooth a invoqué une redirection là où elle n'aurait pas dû.