en v4, il était possible de travailler avec plusieurs onglets ouverts (un pour l’éditeur de code, d’autres pour la configuration des objets, d’autres pour les tests, etc.), de faire un clear cache - y compris global - puis de simplement se reconnecter sur un des onglets, les autres récupéraient la nouvelle session et le contexte de travail de chaque onglet n’était pas perdu (il suffisait de recharger le formulaire ou la liste courante).
en v5, les autres onglets deviennent inutilisables (moulinent dans le vide) et il faut recharger complètement la page dans le navigateur puis recharger le contexte initial (éditeur de code, configuration d’objet, etc.).
Est-ce lié à un changement structurant dans la gestion du cache ou des sessions ?
C’était très pratique et permettait de gagner un temps certain.
C’est toujours la même logique à priori entre la V4 et V5.
Vous avez surement un décalage de paramétrage ou d’authentification.
Peut-être qu’en V4 vous utilisiez les token de session Simplicité ? Cela permet de recréer/retrouver une session “longue” si celle de tomcat est morte.
Ou vous passiez par une autre logique de valve/filtre/auth2 qui ne retrouve pas la nouvelle session dans les autres onglets ?
Perso, j’active tous les USE_USERTOKENS = all pour tout accès API+UI (token stocké en base) et ça fonctionne avec une authent locale “designer”.
Si c’est un pb de filtre/valve, il faudra creuser le point pour voir la différence.
Nous utilisons généralement les tokens fournis par notre IDP (plus rarement les connexions directes Simplicité). Le choix du provider n’avait aucune incidence sur le comportement des sessions lors des clear cache. Aucun changement de pratique de ce côté.
Perso, j’active tous les USE_USERTOKENS = all pour tout accès API+UI (token stocké en base)
En effet, en production (v4) nous avons USE_USERTOKENS = api et en dev (v5) USE_USERTOKENS = yes (valeur système par défaut non surchargée). Je vais tester avec USE_USERTOKENS = all.
J’ai testé aussi sans clear cache simplement en me déconnectant (menu quitter) / reconnectant sur un onglet. Avec token Simplicité ou IDP Renault… Idem.
Les autres onglets sont inutilisables sans recharger la page (message “Vous n’êtes pas connecté” puis si je clique sur “Ok”, bandeau gris avec une animation qui mouline en boucle si je ne clique pas sur le bouton “Ok”, page de login sinon).
Bon, ce n’est vraiment pas bloquant. Cependant, si il y avait eu un moyen simple de revenir sur le comportement précédent, c’aurait été très pratique. Tant pis : recharger la page + rouvrir les formulaires via les activités récentes, ça marche aussi.
Au debugger, ça vient du nouveau contrôle CSRF mis en place suite à audit de sécurité sur tous les accès UI ajax (servlet json). Le client à l’ouverture de session récupère une clé ajax qu’il ajoute systématiquement aux appels Ajax pour vérifier côté serveur que ça ne vient pas d’ailleurs = ici un autre onglet ouvert avant avec une autre clé, mais ça pourrait être un lien frauduleux dans un email.
“Blocked unsecured access: mismatch Ajax key”
On va essayer de trouver un moyen de rafraichir la clé dans les autres fenêtres filles.
Oui il faut forcement une donnée partagée, car si on ouvre un onglet sans filiation (sans window.open / opener null), il devient impossible de le faire en javascript entre onglets, vu que le clear cache peut venir de n’importe lequel.
Le local storage est bien sécurisé par Application donc invisible d’un site malveillant qui voudrait usurper la session. Je pars là-dessus et on va voir ce que ça donne en version alpha.