Nous constations sur une application en Production en Simplicité 5.1.3, une session (parmi plusieurs : plusieurs fenêtres navigateur affichant chacune l’application sur 1 dossier particulier) peut utiliser les données d’un dossier d’une autre session (autre fenêtre navigateur).
Est-ce une limitation / dysfonctionnement dans l’absolu ou de la version ? Si oui quelle est la trajectoire de résolution ?
Cela pourrait-il venir d’un effet de bord de paramétrage ? Dans ce cas y a-t-il un contournement possible ?
Merci
Cordialement,
----description of the request----
Steps to reproduce
This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:
La première chose que je constate c’est que vous êtes en 5.1.3, la release actuelle est la 5.2.31 et comporte plusieurs patch de sécurité, notamment le fix de la vulnérabilité Log4j de décembre 2021 : Log4j 2.x vulnerability - UPDATED
Il serait judicieux de vous mettre à jour rapidement sur au moins la 5.1.56 (dernière révision de la 5.1)
Concernant le bug que tu décris, qu’est-ce que tu entends par :
Peux-tu spécifier une procédure pour reproduire le bug ?
OK pour l’upgrade. On y travaillera dans les meilleurs délais.
=> des changements notables dans cette version pouvant nous impacter ?
Pour la description du dysfonctionnement, cela sera plus simple avec un exemple.
L’utilisateur ouvre 3 fenêtres navigateur sur chacune d’elle il se met sur un dossier :
Session 1 : dossier 1
Session 2 : dossier 2
Session 3 : dossier 3
il se positionne sur la session 3 et fait une action (exemple une affectation), il arrive que la notification transmise par le système fasse référence au dossier 1 ou 2 (au lieu du 3)
Je ne sais pas si c’es facilement reproductible mais cela est avéré. Malheureusement je n’ai pas de logs …
L’architecture actuelle est basée sur une session TOMCAT avec un cookie JSESSIONID.
Donc ouvrir N onglets dans un même navigateur authentifié, c’est travailler en parallèle dans 1 seule et même session serveur = regardez le cookie de vos onglets, c’est le même, donc vu du serveur les requêtes qu’il reçoit viennent de la “même page”, il n’y a aucune notion d’onglet séparé.
Suivant votre navigation dans les 2 onglets, en back les données vont potentiellement se mélanger (valeurs/recherche courantes dans l’instance d’objet, son parent object…).
C’est donc à proscrire.
Il faut former vos utilisateurs qui ont besoin de plusieurs “sessions uniques” à ouvrir plusieurs navigateurs distincts (chrome + safari + FF + edge + des sessions privées…).
Par contre c’est effectivement peu compréhensible pour un utilisateur lambda non habitué aux architectures client/serveur/stateful.
Votre besoin est une feature request :
on va étudier la possibilité de générer un “identifiant client par onglet”
qui sera envoyé au serveur à chaque appel en plus du JSESSIONID
le serveur pourra alors créer/utiliser des “instances d’objet par onglet”
mais il y aura toujours une mutualisation de certaines ressources (typiquement la session tomcat, les Grant, les paramètres systèmes…), ce ne sera en aucun cas une nouvelle session/avec un nouvelle authentification.