Discussion :

[marinew]

Bonjour,

Nous utilisons ASP.Net pour des applications de gestion, en stockant les paramètres en session, pour les transmettre d'une page à l'autre.
Problème : si l'utilisateur ouvre l'appli dans un 2e onglet ou une 2e fenêtre du navigateur, les variables de session sont écrasées. Quand on revient sur le 1er onglet, les données affichées ne sont plus du tout en phase avec les paramètres en session, et ça devient vite le bazar.

Je vois 2 pistes :
- Passer les paramètres de page à page par autre mécanisme que la session
=> Par le ViewState ?? Mais comment, puisqu'il est au niveau des composants, et pas au niveau de la page ?
- Réussir à détecter que l'utilisateur a ouvert un nouvel onglet/fenêtre, et générer un identifiant différent pour chaque onglet, qui sert de suffixe aux clefs des variables stockées en session.
=> C'est à priori possible de détecter l'ouverture d'un nouvel onglet en jouant avec le window.name côté client. Mais j'ai ensuite des difficultés à remonter l'info côté serveur. J'y arrive en ajoutant dynamiquement un champs caché dans le formulaire, mais si la personne modifie l'URL et valide, on est en GET (et non plus en POST), et le champs caché ne remonte pas vers le serveur, on n'a donc plus accès aux variables en session !

J'ai fait des recherches et des tests dans ces 2 sens, mais je n'arrive à rien de concret.

Quelqu'un aurait-il trouvé une solution à cette problématique (sur une de ces 2 pistes ou sur toute autre idée), ou des infos pour me mettre sur le bon chemin ?

Merci d'avance.
Marine

[Arthis]

En ouvrant deux onglets tu te retrouves avec l'accès à la même session. Donc si dans chacun des onglets tu accèdes aux mêmes objets stockés en session, il risque en effet d'y avoir du grabuge!

Si tu passes d'une page test1.aspx à test2.aspx, tu vas perdre ton viewstate car celui ne fonctionnera qu'en circuit fermé sur une page en postback.

Pour ton cas, afin de ne pas tout redevelopper, je penserais à développer ta propre méthode de persistance. Pour cela tu peux t'appuyer sur ce qui existe déjà mais en y rajoutant un couche supplémentaire. Je m'explique.

Si dans ta session, tu as un objet A. Ce qu'il faut c'est que ton objet A soit différencié pour chacun des onglets qui ouvre ton application. de façon a avoir A et A' et ainsi éviter les problèmes.

Concrètement, la seule façon de le faire est d'envoyer une information dans ton querystring , un identifiant qui te permettrait de savoir à quel objet ( A ou A') la navigation demandée par le client fait référence.Ensuite par exemple un listDictionnary ou une hashtable te permettront de stocker tes différents objets A et d'y accéder en fonction de l'identifiant compris dans ta querystring.

Cela signifie aussi trouver un systeme pour changer cet identifiant à chaque demande (postback ou changement de page), car si quelqu'un copie une Url d'un onglet dans un nouvel onglet, Il va falloir partir de l'objet qui existe déjà et le copier afin de lui faire subir (peut etre) des modifications que l'objet initial ne doit pas subir afin de lui permettre de continuer son propre chemin.

Bref, je te souhaite pas mal de plaisir, cela semble intéressant au moins à faire.

si tu as des questions n'hésites pas, c'était ma pensée du soir, juste avant le repas, j'ai faim, et je suis peut etre passé a coté de deux trois trucs plus simples

[marinew]

Merci beaucoup pour cette pensée du soir, Arthis ! ;-)

C'est en effet la piste la plus sérieuse que j'ai trouvée. J'ai fait des tests en ce sens cet après-midi :
Sur le Body/OnLoad, j'exécute une fonction JavaScript :
- si window.name est vide, je génère un identifiant (heure courante) que je stocke dans window.name, car cette valeur ne bougera pas durant toute la navigation dans cet onglet, et elle sera systématiquement vide quand j'ouvrirai un nouvel onglet ou une nouvelle fenêtre.
- Puis, dans tous les cas (toujours dans le unload), j'ajoute (ou je remplace) dans l'URL, un paramètre "MonParam" avec pour valeur cet identifiant
Côté serveur, je peux alors récupérer cet identifiant, et je l'utilise comme suffixe à mes noms de variables de session :
Session["UnObjet" + IdentifiantOnglet] = uneValeur;

Dans la théorie (car je ne suis pas allée jusqu'au bout), je suppose que ça pourrait marcher. Mais j'ai été confrontée à un problème de droit d'accès à la page :
http://localhost/MonSite/Accueil.aspx fonctionne, mais
http://localhost/MonSite/Accueil.asp...aram=UneValeur m'amenais sur une page d'erreur.
J'en suis restée là, d'autant que l'idée d'avoir un paramètre dans le QueryString (visible par l'utilisateur) me plait moyennement.
Si je n'ai aucune autre piste, je serai peut-être obligée de persévérer là-dessus.

Qu'en penses-tu, Arthis ?

D'autres idées ou expériences peut-être ?

[Arthis]

soit du querystring soit un champ hidden et transmettre tes infos par post plutôt que par get. mais dans ces cas la la navigation entre deux pages ne pourrait se faire que via l'intermédiaire d'un formulaire.

[Philippe Vialatte]

Salut,

tu peux aussi essayer de stocker dans le viewstate/quesystring de ta page un guid, et préfixer tes identifiants de session par ce guid.

On le fait sur une grosse appli en ce moment, ca marche pas mal

[marinew]

Arthis,
j'ai essayé aussi via un HiddenField. Mais ce qui me gêne, c'est que je ne suis pas sûre qu'on soit en GET dans tous les cas de figure. Par exemple quand l'utilisateur saisit l'URL dans son navigateur, on est en GET.

Philippe,
As-tu une idée (un bout de code) sur la façon de stocker le GUID dans le ViewState ? J'ai voulu faire quelque chose comme ça tout à l'heure, mais je me suis aperçue qu'il n'y avait pas de propriété ViewState sur l'objet Page. Alors comment accéder au ViewState (de façon générique de préférence) ?
Et sur votre projet, comment vous-y êtes vous pris plus précisément ?

Merci encore pour votre aide !

[Philippe Vialatte]

As-tu une idée (un bout de code) sur la façon de stocker le GUID dans le ViewState ? J'ai voulu faire quelque chose comme ça tout à l'heure, mais je me suis aperçue qu'il n'y avait pas de propriété ViewState sur l'objet Page. Alors comment accéder au ViewState (de façon générique de préférence) ?

Euh...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
public string ControlUniqueID{
   get{
       if (this.ViewState["ControlUniqueID"] == null)
          this.ViewState["ControlUniqueID"] = Guid.NewGuid();
       return this.ViewState["ControlUniqueID"].ToString();
   }
   set { this.ViewState["ControlUniqueID"] = value; }
}

Et tu utilises, pour récupérer les données, qq chose comme :
Session[this.ControlUniqueId + "truc"]

Après, pour passer les uniqueId entre pages, le plus simple est de passer les paramètres au choix par Url ou par post, mais, dans les deux cas, tu peux accéder indifférement au paramètre en faisant Request[valeur]

Bon, après, ca reste casse-bonbon dans tous les cas

[marinew]

Merci Philippe.
Je viens de percuter, pour mon problème avec le ViewState : j'essayais d'accéder au ViewState de ma page depuis la classe contrôleur associée, et je ne voyais pas de propriété ViewState. Et pour cause : elle est protected.
Si tu dis que ça fonctionne bien chez vous, je vais persévérer dans ce sens.

Encore 2 petites questions si tu veux bien :
- Avez-vous utilisé le paramètre d'URL, ou le Post ? N'avez-vous pas rencontré de difficulté avec l'utilisation de l'un ou l'autre ?
- Comment détectez vous que l'utilisateur envoie sa requête depuis un nouvel onglet du navigateur, et donc qu'il faut générer un nouveau GUID ?

EDIT : j'avais zappé ce que tu disais, Arthis : utiliser le ViewState ne me permettra pas de transférer le GUID d'une page à l'autre. Donc finalement, à moins qu'un détail ne m'échappe, ça n'a pas d'intérêt de le stocker dans le ViewState...

[Philippe Vialatte]

- Comment détectez vous que l'utilisateur envoie sa requête depuis un nouvel onglet du navigateur, et donc qu'il faut générer un nouveau GUID ?

Alors, de notre coté, ce n'est pas exactement le même besoin, mais, si dans Request["uniqueId"], il n'y à rien, alors on génère un nouvel id.

Donc finalement, à moins qu'un détail ne m'échappe, ça n'a pas d'intérêt de le stocker dans le ViewState...

L'interet de le stocker dans le Viewstate, c'est si tu as des requêtes Ajax "façon Updatepanel" sur une page qui n'à pas été appellée avec un uniqueId dans l'url, chaque nouveau chargement de la page va te générer un nouvel uniqueId -> tu perds l'accès à tes données en session

[Arthis]

Je plussoie Philippe, si je puis me permettre. La navigation interpage est impossible avec le viewstate, mais si tu reste sur la même page cela peut être un très bon moyen de garder ton information.

Ensuite, get ou post, j'aurais une préférence pour get car plus universel pour accéder à une page mais le post ferais très bien l'affaire aussi. Après je dirais cela dépend beaucoup de ton appli... et de vos choix personnels.

[marinew]

OK pour le ViewState, je comprends l'utilité dans ce cas.
Merci beaucoup à tous les 2, on a maintenant une bonne vision de la chose pour arriver à mettre en place un système de navigations parallèles.
Reste à mettre en pratique, en croisant les doigts pour ne pas avoir trop d'effets de bord...

Bonne journée
Marine

[Kitano]

Salut a tous,
Je suis confronté au même souci !

Pour récupérer le Guid entre les pages, le plus simple n'est-il pas de mettre la propriété "ControlUniqueID" au niveau de la MasterPage (si elle existe bien sûr) ?
Du coup pas besoin de le passer en paramètre, que ce soit via URL ou GET/POST ?!

[dacid]

Bonjour @ tous,

Je viens de rencontrer le même problème (je suis en ASP NET).
Je me connecte dans une fenêtre, Ok. J'en ouvre une autre et me connecte dedans: Ca écrase la session de la 2ème fenêtre... J'ai 2 fenêtres avec la même session.

Je trouve ça ahurissant, la définition même de la session est qu'elle est liée à une et une seule fenêtre.

Quelqu'un a une réponse plus orientée paramétrage ?

[Philippe Vialatte]

Si ca n'est pas du déterrage...

Je trouve ça ahurissant, la définition même de la session est qu'elle est liée à une et une seule fenêtre.

Quelqu'un a une réponse plus orientée paramétrage ?

La définition de la session, c'est qu'elle est liée a un utilisateur et a un virtual directory, donc, dans ton cas, le comportement est normal, si tu veux ouvrir ton application dans N fenètres différentes du même navigateur, oublie la session

[dacid]

Oui, en approfondissant, je suis tombé sur cet article qui a confirmé mes craintes.
http://www.developpez.net/forums/d11...e-navigateurs/

C'est quoi le principe des sessions qui s’appuient sur les URI ?

[Philippe Vialatte]

C'est quoi le principe des sessions qui s’appuient sur les URI ?

Un truc moche...

En gros, la valeur qui aurait du se trouver dans un cookie est transmise dans l'URL
Donc, n'importe qui qui regarde le réseau peut récupérer un ID de session valide

[marinew]

Bonjour,

Etant à l'origine du post, je peux vous dire, presque 2 ans plus tard, qu'on n'a pas trouvé de solution à notre problème initial.
On a abandonné le sujet, après avoir décidé d'adopter une règle de sécurité : quand on a un formulaire de mise à jour d'une entité, il faut toujours stocker son identifiant dans un champs caché du formulaire, et utiliser ce champs caché et non pas l'identifiant mémorisé en session, pour éviter de faire un Update sur la mauvaise entité !

Pour répondre à ta question sur les URI, dacid, regarde la doc MSDN du côté de la propriété "cookieless" du paramètre "sessionState" du Web.config.

[dacid]

Aie.
En effet, ça ne m’intéresse pas.

Il n'y pas de façon de dire dans le Web.config de passer les variables de sessions dans les POST plutôt que les cookies, par exemple ?