Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement ASP.Net SessionId et Nouvelle fenêtre dans IE

SessionId et Nouvelle fenêtre dans IE

16 réponses
Avatar
Patrick Paquin
Bonjour,

Lorsque qu'un usager d'une l'application Web fait "Fichier -> Nouveau ->
Fenêtre" ou bien Ctrl+N dans IE, l'usager obtient 2 fenêtres IE ayant le
même SessionId. Ceci pose problème lorsque, dans certain formulaire Web,
nous utilisons une variable de session pour stocker un dataset. Le fait que
l'usager navigue avec 2 fenêtre sur la même application et avec la même
session peut donner des résultats inattendus.

Est-il possible d'avoir un Id de fenêtre qui nous permettrait de nommer les
variable de session avec cet Id et ainsi avoir un nom unique par fenêtre
ouverte avec le même SessionId?

Merci
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Patrick Paquin
Bonjour Fred,

Après vérification, le port est le même. C'est la variable REMOTE PORT de la
collection Request.ServerVariables qui nous donne cette information. Deux
instances de IE donnent 2 ports clients différents, mais, dans notre cas, ce
n'est pas 2 instances (ou processus). Lorsque nous demandons l'ouverture
d'une nouvelle fenêtre (CTRL + N), les 2 fenêtres appartienne au même
processus contrairement à l'ouverture de 2 fenêtres ouvertes à partir de
iexplorer.exe

"Fred" a écrit dans le message de
news:%

Bonsoir,
Je tente une suggestion car je n'ai pas d'expérience en la matière, mais
j'irais voir du côté du port client s'il est possible de le récupérer
(normalement oui). Une nouvelle instance de IE devrait utiliser un nouveau
port. Non ?

--
Fred





Avatar
Norm
de mon coté il considère que c'est la première fois que la page est loadée à
l'ouverture de la deuxième fenêtre. On nage en plein mystère.


"Patrick Paquin" a écrit dans le message de news:

Il repasse dans le pageload, mais même si c'est une nouvelle fenêtre, il
sait que ce n'est pas la première fois que la page est demandée.

"Norm" a écrit dans le message de
news:
autre possibilité

de mon coté a voir si toi c'est de même

lorsque je fais ctrl-n, et qu'il m'ouvre une nouvelle page et il repasse
dans le page load et dans le if not page.ispostback.
donc, peut-etre que d'initiliaser toute tes valeurs session dans ce if là
courtournerait ton problème!



"Fred" a écrit dans le message de news:
%
> Dans son message %
> Patrick Paquin nous dit :
>
>> Ça ne fonctionne toujours...
>>
>> Est-ce que tu fais une soumission de ton formulaire à l'aide d'un
>> bouton par exemple? Car la valeur dans ton textbox invisible suit
>> dans la nouvelle page si tu l'ouvres après avoir soumis ton
>> formulaire au moins une fois.
>> Le fait que la valeur du textbox revient après une soumission est
>> basé sur les viewstate. Donc on vire en rond! ;)
>>
>>
>> "Norm" a écrit dans le message de
>> news:%23aS$
>>> Mea culpa, peut-être que le viewstate suit sur l'autre page(je
>>> l'utilise pas dans mon application), essayes avec le champ text
>>> caché au lieu de placer la date dans le viewstate.
>>>
>>> mon code:
>>> .aspx je déclare mon textbox
>>> <asp:TextBox Runat=server style="display:none" ID="txtsession" />
>>>
>>> coté server:
>>> If txtSession.Text = "" Then
>>> txtSession.Text = Now.ToString
>>> End If
>>>
>>> ma facon d'utiliser la session, ex:
>>> Session( txtSession.Text & "mavariable") = "patate"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> "Patrick Paquin" a écrit dans le message de
>>> news:
>>>> Je viens de faire le test et ça ne fonctionne toujours pas, voici
>>>> le test que j'ai fait :
>>>>
>>>> J'ai créé un nouveau formulaire sur lequel j'ai ajouté avec un
>>>> bouton (contrôle serveur) qui n'a aucun code dans l'événement
>>>> onclick. J'ai ajouté
>>>> ce bouton pour que le formulaire puisse être soumis. Dans le page
>>>> load
>>>
>>>>
>>>> Response.Write(IsNothing(ViewState("test")))
>>>> If IsNothing(ViewState("test")) Then ViewState("test") = Now
>>>> Response.Write(":" & ViewState("test"))
>>>>
>>>> Voici les étapes... j'affiche dans mon navigateur le formulaire, la
>>>> réponse
>>>> "True : 2005-05-25 10:10:13 "
>>>> Je clique sur le bouton, la réponse : "False : 2005-05-25 10:10:13"
>>>> Je fais Fichier -> Nouveau -> Fenêtre, dans la nouvelle fenêtre la
>>>> réponse est "False : 2005-05-25 10:10:13"
>>>>
>>>>
>>>> "Norm" a écrit dans le message de
>>>> news:
>>>>> Non le viewstate ne suivra pas et le champ texte contenant la date
>>>>> sera vide.
>>>>> Je l'utilise dans une application et cela marche très bien. les
>>>>> date ne sont pas identiques.
>>>>> tu peux même mettre l'assignation direct dans le load et non le If
>>>>> Not IsPostBack() Then
>>>>> 'empeche d'écraser
>>>>> If txtSession.Text = "" Then
>>>>> txtSession.Text = Now.ToString
>>>>> End If
>>>>>
>>>>>
>>>>>
>>>>> "Patrick Paquin" a écrit dans le message de
>>>>> news: elC$
>>>>>> Je comprends ce que tu me proposes mais je ne suis pas sûr que ça
>>>>>> peut régler le problème. En ouvrant la nouvelle fenêtre, la même
>>>>>> page s'affiche
>>>>>> dans le même état (ViewState va suivre). Et donc, le input
>>>>>> hidden va contenir la même date que dans la première fenêtre car
>>>>>> dans le Page Load, on
>>>>>> n'aura pas obtenu un Not IsPostBack pour initialiser le input
>>>>>> hidden une
>>>>>> seconde fois.
>>>>>>
>>>>>> "Norm" a écrit dans le message de
>>>>>> news:%
>>>>>>> Pour contourner ce problème que j'ai déjà eu, tu pourais te
>>>>>>> créer un champ text hidden dans lequel tu mets la date heure
>>>>>>> minute secondes à l'ouverture. ensuite quand tu affectes ou
>>>>>>> récupères des variables Session tu concatènes ce champ text
>>>>>>> dans le nom.
>>>>>>> quelque chose du genre : Session("MaVariable" + txthidden.text).
>>>>>>> Ainsi tu auras une seule session, mais avec les variables en
>>>>>>> "double", mais tu accèdes à la bonne avec le champ text.
>>>>>>>
>>>>>>> Est-ce une solution envisageable?
>>>>>>>
>>>>>>>
>>>>>>> "Patrick Paquin" a écrit dans le message
>>>>>>> de news:
>>>>>>>> Bonjour,
>>>>>>>>
>>>>>>>> Lorsque qu'un usager d'une l'application Web fait "Fichier ->
>>>>>>>> Nouveau ->
>>>>>>>> Fenêtre" ou bien Ctrl+N dans IE, l'usager obtient 2 fenêtres IE
>>>>>>>> ayant
>>>>>>>> le
>>>>>>>> même SessionId. Ceci pose problème lorsque, dans certain
>>>>>>>> formulaire Web, nous utilisons une variable de session pour
>>>>>>>> stocker un dataset.
>> Le
>>>>>>>> fait
>>>>>>>> que
>>>>>>>> l'usager navigue avec 2 fenêtre sur la même application et avec
>>>>>>>> la même session peut donner des résultats inattendus.
>>>>>>>>
>>>>>>>> Est-il possible d'avoir un Id de fenêtre qui nous permettrait
>>>>>>>> de nommer les
>>>>>>>> variable de session avec cet Id et ainsi avoir un nom unique par
>>>>>>>> fenêtre
>>>>>>>> ouverte avec le même SessionId?
>>>>>>>>
>>>>>>>> Merci
>
> Bonsoir,
> Je tente une suggestion car je n'ai pas d'expérience en la matière,
> mais
> j'irais voir du côté du port client s'il est possible de le récupérer
> (normalement oui). Une nouvelle instance de IE devrait utiliser un


nouveau
> port. Non ?
>
> --
> Fred
>
>
>








Avatar
Fred
Dans son message
Patrick Paquin nous dit :

Bonjour Fred,

Après vérification, le port est le même. C'est la variable REMOTE
PORT de la collection Request.ServerVariables qui nous donne cette
information. Deux instances de IE donnent 2 ports clients
différents, mais, dans notre cas, ce n'est pas 2 instances (ou
processus). Lorsque nous demandons l'ouverture d'une nouvelle
fenêtre (CTRL + N), les 2 fenêtres appartienne au même processus
contrairement à l'ouverture de 2 fenêtres ouvertes à partir de
iexplorer.exe





Oui, je viens de tester avec mon firewall.
Tant pis.
Votre problème me fait penser aux attaques par rejeu. Peut-on considérer que
le problème est similaire ?
N'existe-t-il pas des méthodes de programmation connues contre cela ?
Je ferai une petite recherche, cela m'intéresse. Ainsi que l'issue de votre
discussion si vous parvenez à une solution (qui fonctionne pour vous deux
j'entends)
Bonne soirée.

--
Fred
Avatar
Simon Mourier
C'est un problème de conception. HTTP est un protocole conçu pour être sans
état. La session est une notion ASP.NET (qui n'a rien à voir avec HTTP) liée
aux cookies clients (cookies de session, c'est à dire non persistants) ou à
l'url (mode ASP.NET CookieLess).

Au sens HTTP, les cookies sont véhiculés par le "user agent" (qui peut ou
non supporter les cookies d'ailleurs, en fonction de sa configuration). Les
"user agents" les plus connus sont IE, FireFox, etc...

La notion de fenêtre de IE, et la façon dont il gère les cookies d'une
fenêtre à l'autre est donc purement liée au "user agent" IE. Il se trouve
que les cookies de session sont liés au processus (au sens Windows) de IE,
c'est à dire IEXPLORE.EXE (ou autre si c'est un IE hébergé). Par défaut,
quand on crée une nouvelle fenêtre IE (ctrl n), on reste dans le même
processus, et on dispose donc de la même session. Il faut noter d'ailleurs
que les anciennes versions de IE (3 et 4 je crois) ne fonctionnait pas comme
cela, il y avait une option "Browse in a new process" qui permettait de
créer une nouvelle fenêtre sur un nouveau processus et donc une nouvelle
session...

Et même si vous résolvez le problème aujourd'hui, sachez qu'il pourra
réapparaitre avec un nouvel IE (ce serait étonnant mais ...), ou avec un
autre "user agent" gérant différemment ses fenêtres, car la notion de
"fenêtre" n'existe pas pour HTTP...

Donc pour résoudre ce problème, il faut créer cette notion de "fenêtre
client" par vous même, à la main, et vous débrouiller pour la transporter
vers le serveur à chaque requete.
Vu que c'est à chaque requête, vous ne pouvez pas passer par les cookies
(globaux au processus, donc à toutes les fenêtres). Il ne reste que les
champs cachés (ou les urls mais c'est plus difficile). Il faut donc créer un
champ caché "id de fenetre" envoyé par le browser à chaque requête, et
renvoyé par le serveur (identique à la valeur envoyée) à chaque réponse. A
votre place

1) je créerai un petit code Javascript qui vérifiera pour chaque fenête si
il existe sur la page un champ caché "windowID", si il n'existe pas il le
crée (random).
2) Du coté serveur, il faut utiliser ce windowID comme offset au niveau de
tous les stockages en session: Session("dataset" + windowId) = myDataSet; et
le renvoyer tel quel à chaque réponse.

Simon.
www.softfluent.com


"Patrick Paquin" a écrit dans le message de news:

Bonjour,

Lorsque qu'un usager d'une l'application Web fait "Fichier -> Nouveau ->
Fenêtre" ou bien Ctrl+N dans IE, l'usager obtient 2 fenêtres IE ayant le
même SessionId. Ceci pose problème lorsque, dans certain formulaire Web,
nous utilisons une variable de session pour stocker un dataset. Le fait
que
l'usager navigue avec 2 fenêtre sur la même application et avec la même
session peut donner des résultats inattendus.

Est-il possible d'avoir un Id de fenêtre qui nous permettrait de nommer
les
variable de session avec cet Id et ainsi avoir un nom unique par fenêtre
ouverte avec le même SessionId?

Merci




Avatar
Simon Mourier
J'ai oublié d'ajouté que le pseudo windowId doit être placée dans la
propriété Window.Name du modèle objet. Par défaut Window.Name ne contient
rien. Une fois qu'on met quelque chose dedans, il conserve cette valeur tant
que la fenêtre IE reste ouverte. Donc il faut un code du genre

if window.name = "" then window.name = now ou random ou quelque chose
d'unique

Simon.
www.softfluent.com

"Simon Mourier" a écrit dans le message de news:
u1J$
C'est un problème de conception. HTTP est un protocole conçu pour être
sans état. La session est une notion ASP.NET (qui n'a rien à voir avec
HTTP) liée aux cookies clients (cookies de session, c'est à dire non
persistants) ou à l'url (mode ASP.NET CookieLess).

Au sens HTTP, les cookies sont véhiculés par le "user agent" (qui peut ou
non supporter les cookies d'ailleurs, en fonction de sa configuration).
Les "user agents" les plus connus sont IE, FireFox, etc...

La notion de fenêtre de IE, et la façon dont il gère les cookies d'une
fenêtre à l'autre est donc purement liée au "user agent" IE. Il se trouve
que les cookies de session sont liés au processus (au sens Windows) de IE,
c'est à dire IEXPLORE.EXE (ou autre si c'est un IE hébergé). Par défaut,
quand on crée une nouvelle fenêtre IE (ctrl n), on reste dans le même
processus, et on dispose donc de la même session. Il faut noter d'ailleurs
que les anciennes versions de IE (3 et 4 je crois) ne fonctionnait pas
comme cela, il y avait une option "Browse in a new process" qui permettait
de créer une nouvelle fenêtre sur un nouveau processus et donc une
nouvelle session...

Et même si vous résolvez le problème aujourd'hui, sachez qu'il pourra
réapparaitre avec un nouvel IE (ce serait étonnant mais ...), ou avec un
autre "user agent" gérant différemment ses fenêtres, car la notion de
"fenêtre" n'existe pas pour HTTP...

Donc pour résoudre ce problème, il faut créer cette notion de "fenêtre
client" par vous même, à la main, et vous débrouiller pour la transporter
vers le serveur à chaque requete.
Vu que c'est à chaque requête, vous ne pouvez pas passer par les cookies
(globaux au processus, donc à toutes les fenêtres). Il ne reste que les
champs cachés (ou les urls mais c'est plus difficile). Il faut donc créer
un champ caché "id de fenetre" envoyé par le browser à chaque requête, et
renvoyé par le serveur (identique à la valeur envoyée) à chaque réponse. A
votre place

1) je créerai un petit code Javascript qui vérifiera pour chaque fenête si
il existe sur la page un champ caché "windowID", si il n'existe pas il le
crée (random).
2) Du coté serveur, il faut utiliser ce windowID comme offset au niveau de
tous les stockages en session: Session("dataset" + windowId) = myDataSet;
et le renvoyer tel quel à chaque réponse.

Simon.
www.softfluent.com


"Patrick Paquin" a écrit dans le message de news:

Bonjour,

Lorsque qu'un usager d'une l'application Web fait "Fichier -> Nouveau ->
Fenêtre" ou bien Ctrl+N dans IE, l'usager obtient 2 fenêtres IE ayant le
même SessionId. Ceci pose problème lorsque, dans certain formulaire Web,
nous utilisons une variable de session pour stocker un dataset. Le fait
que
l'usager navigue avec 2 fenêtre sur la même application et avec la même
session peut donner des résultats inattendus.

Est-il possible d'avoir un Id de fenêtre qui nous permettrait de nommer
les
variable de session avec cet Id et ainsi avoir un nom unique par fenêtre
ouverte avec le même SessionId?

Merci








Avatar
Patrick Paquin
Cette solution semble très intéressante, merci pour toutes ces
informations.

Je vois un seul hic que je vous avec cette technique. À chaque premier
chargement d'un formulaire, le champs caché sera vide car il sera initialisé
côté du client donc après le chargement initial côté client. Car, par
exemple, dans une page où l'on fait un lien du genre <a href="..."> aucun
champs n'est passé à moins de les passés explicement du genre <a
href="...?wn 040525142354".

Voici donc la solution pour laquelle je vais opter en considérant que je
suis dans un contexte d'application intranet avec plateforme normalisée.

Dans la page d'identification de l'application, j'initialiserai Window.Name
en fonction avec la date heure seconde de l'identification côté client et je
passerai cette valeur au serveur pour qu'il garde cette valeur dans une
variable de session nommé ex. WindowName. Ensuite, dans les formulaires
utilisant des variables de session (ce que nous évitons le plus possible
pour minimiser les ressources utilisées), un paramètre spécifiant le nom de
la fenêtre devra leur être passé explicitement et dans le Page Load du
formulaire, un validation de la concordonnance des 2 valeurs (Variable
Session WindowName et le paramètre). Si le test échoue une redirection côté
serveur sera effectué sur la page d'identification.

Si vous avez des suggestions pour éviter d'avoir à passer de façon explite
le nom de la fenêtre, ne vous gêner pour le soumettre sur le forum.

Merci à tous
1 2