Envole » Envole-Mutualisé » eole-dispatcher

Après une journée d'investigation, voici mon analyse :

un vieux cookie dispatcher est présent sur le poste

on demande une connexion à edispatcher

edispatcher voit que la session existe mais qu'elle n'est plus bonne (vieux cookie), il demande donc un ticket à eolesso

eolesso fait l'authentification, crée un ticket, l'envoie au client

mais edispatcher réutilise à nouveau le vieux cookie > là on entre dans la boucle

comme la session liée à ce cookie n'est pas bonne, du coup il redemande la vérification à eolesso

eolesso répond à nouveau "cet utilisateur est ok"

edispatcher reprend la main mais voit encore que la session est pas bonne

Si on détruit le cookie edispatcher, cela remarche

Le pb se situe au moment ou eolesso répond : edispatcher devrait alors détruire le cookie existant et ne pas rejouer le vieux cookie

Les logs d'erreur d'apache signalés auparavant ("The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,") m'ont incité à faire un dump de cet id dans un fichier texte: il se trouve que quand cette erreur apparait, l'id en question est une chaîne vide (le tableau de session est vide également)

J'ai pu le reproduire sur un serveur de test en vidant la value (correspondant à l'ID) du cookie. Lorsque je rappelais ma page edispatcher ensuite, j'étais dans la boucle de redirection
Cependant cela s'est produit aussi sur le poste d'un collègue mais la value ne son cookie n'était pas vide. Je n'avais malheureusement pas encore fait le dump à ce moment-là
Dans les logs d'apache du serveur de prod l'erreur "The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-" apparait relativement souvent
Dans mon dump, lorsque l'erreur apparaît, il est toujours vide

Je soupçonne que même si côté client l'ID n'est pas vide, le cookie n'est plus reconnu côté serveur car le garbage collector de PHP est passé et à supprimé la référence à cet id, donc côté serveur cet ID n'existe plus et il le considère comme vide

En cherchant un peu, j'ai vu qu'il y avait un moyen relativement simple de supprimer ce problème : il faudrait passer la variable de configuration session.use_strict_mode à 1 dans php.ini

http://php.net/manual/en/session.configuration.php#ini.session.use-strict-mode

Cette variable n'est visiblement pas initialisée par défaut sur les serveurs envole et malheureusement par défaut elle est à 0

Elle force le serveur à refuser les cookies non-initialisés côté serveur, et à régénérer un cookie si le cookie envoyé par le client est invalide

Je ne sais pas si cela peut avoir des conséquences sur le reste mais en tout cas j'ai fait un test sur notre serveur de test, et cela marche parfaitement

Dans php.ini :
session.use_strict_mode = 1

Si je vide la value du cookie edispatcher et que je refreshe la page, un nouvel id est régénéré et ma page s'affiche désormais correctement, je n'ai plus la boucle

Le problème est que pour modifier cela, on touche au php.ini qui n'est plus du ressort du dev de dispatcher

Je propose donc d'ajouter une ligne ini_set() dans le fichier include/inc.php :
Juste avant la partie session (après le comment)

// Gestion de l'authentification
ini_set('session.use_strict_mode', '1');
if (session_status() == PHP_SESSION_NONE) {

J'ai fait le test et j'ai le même comportement qu'en modifiant le php.ini : je n'ai plus la boucle si je vide la value du cookie

Concernant le problème de boucle proprement dit, je pense avoir identifié le pb :

Dans le template de logout (logout.html.twig, appelé par l'url ng/logout), une fonction JS clearCookie, ayant pour objectif de faire expirer les cookies, n'a pas l'effet attendu :
1) la fonction Date qui sert à initialiser la date d'expiration du cookie ne marche pas et le cookie généré n'a pas de date d'expiration
2) en outre le cookie ainsi créé n'a pas de value, donc pas d'ID

Ce qui fait que lorsqu'un utilisateur a cliqué sur logout, il se retrouve avec un cookie vide, qui est envoyé au serveur à la prochaine reconnexion. Le serveur ne sait comment gérer ce cookie, car il ne peut pas enregistrer de fichier de session avec un nom vide. (D'ou les nombreuses erreurs dans les logs apache "Illegal character"....). La session n'est pas créée et du coup le ticket eolesso est constamment demandé, d'où la boucle.

3) enfin dernière remarque : le domaine du cookie généré est assorti d'un "." initial (.estereL.ac-nice.fr chez nous). Apparemment c'est un fonctionnement normal de javascript (si on veut avoir le domaine exact, il faut en fait laisser cet attribut vide et ne pas lui envoyer document.domain). Cela dit, cette erreur permet en fait de ne pas avoir la boucle dans la majorité des cas, puisque du coup le cookie vide ne remplace pas le cookie edispatcher (ce qui était son rôle au départ) mais est ajouté. A la reconnexion suivante, le client envoie donc 2 cookies edispatcher, un pour esterel.ac-nice.fr (celui de la session précédente, qui a bien un ID) et un pour .esterel.ac-nice.fr (celui créé par la fonction clearCookie). Le serveur remonte bien une erreur pour le cookie vide, mais parvient à créer la session pour l'autre cookie.

Comment régler le problème ?

Il y a plusieurs possibilités :

1) Technologie : javascript ou PHP ?
A priori je serais plus PHP si on arrive à le faire correctement. Le server-side me plait toujours plus que le client-side... Le seul avantage du JS est que la fonction peut être facilement modifiée avec le système de template. Le JS peut être une première solution, qui permettra d'aller vite en attendant une solution PHP qui viendra forcément d'un nouveau paquet. EN cas de php, il faudra le mettre dans la fonction logoutaction()

2) Contenu du cookie :
a) mettre une bonne date (en JS il faut tester, mais le pb semble venir du fait que ce n'est pas au format UTC, voir toUTCString())
b) affecter un ID au cookie :
- soit celui de l'ID du cookie de la session, voir si on peut le récupérer en JS
- soit un contenu statique, par exemple "logout"), ou un mélange d'infos statiques et dynamiques ("logout_IDdesession_date_heure")
c) vérifier si appeler le Cas:logout() permet de supprimer proprement le cookie edispatcher, on peut utiliser cela

3) En plus de cela, affecter une durée de validité au cookie à la connexion, avec un session_set_cookie_params(secondes). Cela permettrait que les personnes qui ne cliquent pas sur déconnexion soient bien déloguées au bout d'un moment. Firefox est souvent paramétré pour conserver les cookies, même après fermeture, et j'ai vu beaucoup trop de gens qui ne cliquaient pas sur "se déconnecter" mais fermaient simplement l'onglet ou la page du PIA (et parfois ne quittaient même pas le navigateur car d'autres fenetres étaient ouvertes)

Proposition pour le javascript :
- j'utilise l'attribut max-age plutôt que expires (plus facile à gérer, voir si cela fonctionne sur tous les navigateurs...) et je mets la durée de validité du cookie à une seconde (je n'ai pas testé la valeur 0)
- dans la value, plutôt que de mettre du vide, je met le nom du cookie suivi de "_logout" (ex : edispatcher_logout)
- plus de domaine, il est automatiquement bien renseigné
- les 2 alert sont pour voir les cookies se modifier (et disparaître) au fur et à mesure, ils seront bien sûr à virer en production

    function clearCookie(name, path){
    alert(document.cookie); 

        var path = path || "/";
        var c_value =  name+"_logout; max-age=1; path="+path;
        document.cookie = name + "=" + c_value;
    alert(document.cookie);
 };

Merci encore pour ces investigations

Pour le expires et max-age.
expires fixe la date max et max-age le temps restant le cookie a vivre

A priori y a que IE qui ne supportent pas max-age

Dans un premier temps ont peut effectivement tester en js
Je suis d'accord il est nécessaire de le faire coté serveur.
L'action logout côté controlleur devrait appeler le CasLogout , je testerais chez nous

Je pense qu'il serait intéressant d'inclure dans le logout la destruction des cookies d'autres applications (wordpress, grr, etc...)

Le pb est qu'il est difficile de le lister en dur dans le code

J'ai imaginé une solution radicale : détruire tous les cookies liés à la session... Est-ce que ça ne risque pas d'avoir des effets de bords ?
Si ça n'en a pas, ce serait le plus simple et le plus efficace

      foreach ($_COOKIE as $cookie=>$value) {
          setcookie($cookie, $cookie.'logout', time()+1, '/') ; 
      }

Sinon, se construire à part un tableau des cookies que l'on veut supprimer
genre config/local/cookiestodestroy.inc.php
et dans le code :

     foreach ($_COOKIE as $cookie=>$value) {
          if (in_array($cookie, $cookiestodestroy)) {
          setcookie($cookie, $cookie.'logout', time()+1, '/') ; 
      }

Mais cela obligerait l'admin à connaître les cookies qu'il souhaite supprimer... (on pourrait toutefois ajouter à la condition "|| $cookie === "edispatcher" || $cookie === "mxdesktop")

Je ne sais pas : y a-t-il des cookies envole qu'il faut conserver sur un poste client ? Si ce n'est pas le cas, autant tout supprimer...

ou alors plutôt que sur la condition faire un array_push($cookiestodestroy, "edispatcher", "mxdesktop");

Salut,

Je pense que si le serveur mutualise d'autres applis ( hors Envole ) cela peut poser problème effectivement
Peut être avoir une entrée dans gen_config, ou un paramètre géré par appManager, précisant les cookies que l'on souhaite supprimer lors du logout

nbconn, showmenu c'est généré par posh il me semble
_pk_id_1_0fdb et _pk_ses_1_0fdb c'est du piwik, les supprimer fausserait peut être le tracking

Christophe

Voici le code que je propose :

  include_once('/var/www/html/edispatcher/include/cookies.php');

      $cookies2destroy[] = "edispatcher";
      $cookies2destroy[] = "mxdesktop";
      //print_r($cookies2destroy);
      $cookies = array_keys($_COOKIE);
      $badcookies = array_diff($cookies2destroy,$cookies);
      if ($badcookies) {
          echo "<script>console.log('ATTENTION : DES COOKIES A SUPPRIMER DU FICHIER include/cookies.php NE SONT PAS REELEMENT PRESENTS :');";
          foreach ($badcookies as $badcookie) {
              echo "console.log('- COOKIE : ".$badcookie."');";
          }
          echo "</script>";
      }
      $cookies2reallydestroy = array_intersect($cookies2destroy,$cookies);
      foreach ($cookies2reallydestroy as $c) {
          //  echo "COOKIE A DETRUIRE : ".$c."<br>";
          setcookie($c, time().$c.'logout', time()+1, '/');
      }

On confontre une liste préexistante de cookies qu'on veut supprimer au tableau des cookies existants
On fait un petit warning dans la console si des cookies de la liste n'existent pas
Et on supprime ceux qui sont dans la liste et qui sont réellement présents
Bien sur on ajoute automatiquement edispatcher et mxdesktop à la liste, puisque ceux-là, on est surs qu'il faut les virer

La seule question qui reste : est-ce qu'on fait un système identique à la variable gen_config edispatcher_logouts ou bien on laisse un fichier à part (comme j'ai fait pour l'instant)
Et est-ce qu'on laisse coexister les 2 modes (iframes ET cookies) ou on n'en laisse plus qu'un seul
on pourrait utiliser le tableau _LOGOUTS pour avoir les valeurs des cookies mais dans ce cas il ne faurdrait plus qu'il y ait des urls dedans...
Ou alors on laisse le choix mais dans ce cas il faut bien documenter ce parametre...

Je pense qu'il serait bon, à la création des 2 cookies "edispatcher" et "mxdesktop", de leur assigner une durée de validité
Avec session_set_cookie_params() ou bien avec setcookie()

Il faut quand même en discuter car cela peut avoir un impact

Deux autres petites choses qui me chiffonent :

- Au logout, un cookie "valide" edispatcher est toujours immédiatement recréé, je ne comprends pas pourquoi
- Il semble que le test "IS VALID SESSION" de inc.php renvoie toujours false, donc on rentre toujours dans ce if et le session_start semble être exécuté un grand nombre de fois...