Problème non bloquant en v5 sur la gestion des sessions lorsqu'on a plusieurs onglets de navigateur ouverts en parallèle

Bonjour,

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.

Bonjour,

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.

Merci beaucoup pour ton retour rapide.

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.

A priori, USE_USERTOKENS = all ne change rien.

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.

On va regarder car avant on pouvait bien éditer son modèle en // dans la même session.

@david ça te dit qq chose ? la disparition de la valve ou changement dans le filtre du token ?

La valve ne concernait que le endpoint API (/api) donc pour la UI elle ne faisait rien

Ok j’ai bien le même comportement de déconnexion.

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.

1 Like

Il faut peut être la mettre dans le localStorage ? Ainsi elle sera partagée entre les onglets/fenêtres d’une même session navigateur

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.

Ca fonctionne :

  • il n’y a pas de dégradation de perfs d’accéder au local storage à chaque call pour récupérer la bonne clé
  • si le navigateur n’a pas de local storage, on reste sur l’ancien fonctionnement, mais c’est par sécurité car tous les navigateurs modernes en ont un.

On backporte pour la prochaine 5.1.

1 Like

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.