Filtre de session utilisateur perturbé par utilisation d'onglets multiples

[JoffreyB96 (Joffrey)]

Description

Bonjour,
Nous rencontrons aujourd’hui un soucis lié à un User Filter mis en place dans un partie de notre application. Le parcours utilisateur nominal est le suivant :
Accueil global de l’application > liste des clients > Accueil client > Listes des produits, notifications, … rattachées à ce client spécifiquement.

Sachant que l’accueil client peut être accédé depuis une redirection externe ou depuis le parcours nominal décrit ci-dessus, nous avons fait le choix d’implémenter un objet externe. Ce dernier assure la redirection vers le bon accueil client depuis la liste des clients (Simplicité) ou depuis une application externe via une URL spécifique avec les paramètres nécessaires pour identifier le client.

Lors de l’exécution de cet objet externe, nous avons implémenté la mise en place d’un filtre sur la session utilisateur courante afin de filtrer les listes des produits, notifications, … propres au client courant.

getGrant().getUserFilters().addFieldFilter("clientId", clientIdRet, false, true);

Problème : Si un utilisateur ouvre deux onglets, on se retrouve avec des conflits sur le filtre appliqué.

Nous avons donc tenté d’utiliser le ClientTabId afin de passer par un attribut de session utilisateur :

getGrant().setSessionAttribute​("clientId_[tabId]", clientId);

Puis d’appliquer manuellement les filtre à chaque liste, lorsque cela est nécessaire :

initList {

@Override
public void initList(ObjectDB parent) {
        // Si un attribut de session avec le nom : clientId_[tabId courant] existe, alors :
		getField("clientId").setFilter(getSessionAttribute(clientId_[tabId courant], "");
        getField("clientId").setFilterFixed(ObjectField.FIXED_FILTER_HIDE)
}

Nous avons alors constaté que peu importe l’onglet sur lequel nous testions cette implémentation, le tabId était toujours le même (tabId_onglet_1 = tabId_onglet_2).

Etapes pour reproduction

1. (Onglet 1) Avec le code nécessaire mis en place, déclencher l’exécution de l’objet externe qui va set le session attribute avec le tabId. Nous sommes alors sur l’accueil client A
2. (Onglet 1) Accéder à l’une des listes depuis l’accueil client A et constater que la liste est bien filtrer en fonction de ce même client A.
3. (Onglet 2) Avec le code nécessaire mis en place, déclencher l’exécution de l’objet externe qui va set le session attribute avec le tabId. Nous sommes alors sur l’accueil client B
4. (Onglet 2) Accéder à l’une des listes depuis l’accueil client B et constater que la liste est bien filtrer en fonction de ce même client B.
5. (Onglet 1) Via le fil d’ariane, recharger la liste filtré avec le clientId du client A. *

C’est ici que nous constatons que la liste est en faite maintenant filtré avec le clientId du client B.

5’. (Onglet 1) Via le fil d’ariane, revenir sur l’accueil client (ce qui ne déclenche pas le passage par l’objet externe et donc n’exécute pas la remise en place de notre User filter) puis accéder à une des listes.

Nous constatons là encore que la liste est filtré pour le client B et non le client A.

Informations techniques

Nous avons pu reproduire ce comportement sur une version 6.2.7. Nous sommes actuellement en 6.2.2 sur le projet

Question support

Nous souhaiterions savoir si le fait que nos deux onglet renvoie le même tabId est normal ou s’il s’agit d’une régression ?
Si cela est normal, la solution envisagée n’est donc pas la bonne. Quelles sont vos préconisations pour éviter ce problème que nous rencontrons actuellement ?

[Francois (François Genestin)]

Bonjour,

Pouvez vous préciser le code de votre objet externe et le endpoint/URL utilisée pour y accéder ?

Ce qu’il faut savoir :

• les user-filters sont positionnés au niveau de la session/grant : donc ils seront partagés par tous les onglets d’une même session tomcat. Ca ne semble donc pas adapté à votre besoin de filtrage métier par onglet d’une même session web.

• le _tabId est positionné pour chaque onglet dans le Session storage du navigateur (regardez sa valeur, le session storage est bien par onglet, contrairement au local storage), et en back il n’est pris en compte que pour la UI = donc uniquement pour les accès via servlet /ui/json, où le front ajoute ce paramètre aux URL :

Vous pouvez regarder les échanges :

Si vous faites des requètes sur un autre end-point, le tabId ne sera pas pris en compte dans l’instanciation des objets back (le cache de session est segmenté via le tabId s’il y en a un). Il faut suivre le chemin de ce paramètre dans vos usages (objet externe ou autre) et tout passe bien par /ui/json.

String tabId = getGrant().getClientTabId();

Sinon on devra regarder de plus près si on peut utiliser le tabId dans votre contexte (autre end-point..).