Session.SessionID vraiment unique???
Norm
J'ose croire que cette clé est unique, mias là des doutes me hantent.
Voici ce qui se passe de temps à autre, pas tout le temps.
J'ouvre une première fois mon intranet. Je place en session des données
(dataset).
J'en ouvre un deuxieme, et lorsque je vais lire ce qu'il y a en session il
récupère les données de ce qu'il y a dans la session du premier.
Avant j'utilisais sessionstate inproc, mais j'ai changer pour stateserver.
Le problème arrive d'une façon ou l'autre.
Ma première idée qui j'espère est fausse est que dans sa facon de créer de
session.sessionid il peut arriver qu'un id soit répéter.
Quelqu'un pour m'éclairer?
Dominic Pelletier
Presque ;)
Avec un niveau de chance peux élevé ;) tu peu arriver a avoir le même
... Concat le OADate a ton SessionID , tu va etre sure que ce sera jamais la
même. ;)
Dominic
"Norm" <No...@Norm.com> wrote in message
news:%238lgM87...@TK2MSFTNGP10.phx.gbl...
Dominic Pelletier
avoir deux GUID semblable pour deux dll différente ;)
Dominic
"Norm" <No...@Norm.com> wrote in message
news:%238lgM87...@TK2MSFTNGP10.phx.gbl...
Norm
Effectivement ca devrait être très très rare, mais c'est arrivé 2-3 fois en
2 semaines.
Trouvé sur msdn:
Identification d'une session
Chaque session ASP.NET active est identifiée et suivie à l'aide d'une chaîne
SessionID 120 bits contenant uniquement les caractères ASCII autorisés dans
les URL. Les valeurs SessionID sont générées à l'aide d'un algorithme qui en
garantit le caractère unique de sorte que les sessions n'entrent pas en
conflit et le caractère aléatoire de sorte qu'un utilisateur malveillant ne
puisse pas utiliser un nouveau SessionID pour calculer le SessionID d'une
session existante.
Les chaînes SessionID sont communiquées sur les demandes client-serveur au
moyen d'un cookie HTTP ou d'une URL modifiée avec la chaîne SessionID
incorporée, selon la configuration des paramètres de l'application.
"Dominic Pelletier" <dominic....@gcomnitech.com> a écrit dans le
message de news:ejSdVC8V...@TK2MSFTNGP09.phx.gbl...
Norm
1- Session(now & "mavariable") = "test"
Comment récupérer ma variable après? mettre la date elle aussi dans une
variable session?
2- Session.SessionId &= now
Le session id n'est-il pas readOnly?
"Dominic Pelletier" <dominic....@gcomnitech.com> a écrit dans le
message de news:eAdI%23A8VE...@TK2MSFTNGP11.phx.gbl...
Dominic Pelletier
Je pense qu'on c mal compris ;)
La concat de la date fonctionne seulement si tu veux te faire
une clé unique a partir de la sessionid alors ca implique pas de changer ton
sessionid par ton sessionid + ta date... car ca tu as pas de controle la
dessus...
mais ta sessions id + ta date , ca depend quesque tu veux faire avec....
tu peux toujours la passer en querystring au page connecter, la mettre dans
le viewstate ou en variable session ... ca depend du niveau de securiter que
tu veux mettre sur la visibiliter de cette cle unique...
Dit moi un peu ce que tu veux faire avec ... Je pourrai pe plus te
conseiller ...
Dominic
"Norm" <No...@Norm.com> wrote in message
news:OQxITP8V...@TK2MSFTNGP09.phx.gbl...
Dominic Pelletier
dans Session["SessionKey"] = Session.SessionID+DateTime.Now.ToOADate();
et tu met ta Session Key Dans tout t variable Session ex`
DataSet ds = new DataSet(); // ton affectation.
string sKey = (string)Session["SessionKey"] ;
Session[sKey+"DataSet"] = ds;
Dominic
"Dominic Pelletier" <dominic....@gcomnitech.com> wrote in message
news:e9xWnW8V...@TK2MSFTNGP09.phx.gbl...
Norm
> La concat de la date fonctionne seulement si tu veux te faire
> une clé unique a partir de la sessionid alors ca implique pas de changer
ton
> sessionid par ton sessionid + ta date... car ca tu as pas de controle la
> dessus...
Ca j'avais compris, le sessionid est readonly
>
> mais ta sessions id + ta date , ca depend quesque tu veux faire avec....
Tout ce que je veux faire c'est de mettre des variables en session.
Session qui est supposé être unique par défaut?
Donc, ma façon de faire:
Session("Application_test_" & "Mondataset") = Mydataset
et je récupère
Dim ds as dataset = Session("Application_test_" & "Mondataset")
le "Application_test_" est pour m'assurer d'avoir des nom uniques entre
application.
Donc concaténer la date ici m'oblige à garder cette date dans une variable.
Je me demande comment deux i.e ouvert sur la même page ont pu avoir le même
sessionid.
à chaque fois que je me connecte sur mon site, il y a une session qui
démarre non? ou bien il peut arriver qu'en ouvrant une deuxieme fenêtre il
récupère le sessionid déja en présence dans la première fe^netre
Norm
n'ira-t-il pas écraser Session["SessionKey"] et la première fenêtre aura
alors perdu ces info.
L'idée de prendre la date au démarrage et de la mettre en querystring, et de
la concaténer pour chaque variable session permetterais d'éviter de la
perdre.
Et si jamais une deuxieme fenêtre utiliserais le meme sessionid, dans la
session il y aurait deux fois les variables, mais sans le meme nom et sans
la meme valeur.
exemple, je pourrais me retrouver avec un
Session("personnelid20042106161616") et Session("personnelid20042106161718")
dans la même session.
Je continue mes recherches pour voir s'il y a une possibilité de réutiliser
un sessionid déja ouvert.
"Dominic Pelletier" <dominic....@gcomnitech.com> a écrit dans le
message de news:uKbyNc8V...@TK2MSFTNGP10.phx.gbl...
Michel Thiffault
en plus ce n'est pas configurable (sauf en passant par le registry). Et les
variables sessions étant sur le serveur les deux utiliseront les mêmes.
Ainsi, si la fenêtre A appèle la page 123.asp et que cette page contient
ceci:
session("qwe") = 4
et que la seconde fenêtre appèle la page 456.asp qui contient ceci:
Response.Write Session("qwe")
le résultat sera 4
Voir à ce sujet: http://www.aspfaq.com/show.asp?id=2172
Norm
Si au moins ca serait toujours le cas. Ca arrive un fois de temps à autre.
Michel Thiffault
$%*!&"/$ de variables session!
Norm
Non merci!
"Michel Thiffault" <mt...@h.ot_m.ai_l.com> a écrit dans le message de
news:%23m0gwOG...@TK2MSFTNGP12.phx.gbl...
Michel Thiffault
refusées ici pour des raisons de "scalability" et on ne s'en porte que
mieux).
Ceci devrait t'aider:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconDecidingOnDataAccessStrategy.asp
Une bonne discussion sur l'utilisation des variables sessions (oserais-je
répéter que je les déteste avec passion):
http://www.15seconds.com/issue/010307.htm
Notre catalogue web semblait ralentir énormément lorsque environ 200
utisateurs concurrents s'y trouvaient. Après avoir retiré les variables
sessions nous avons vu un "peak" de 450 utilisateurs concurents et tout ce
passait toujours bien.
Bon, j'arrête mon évangélisation! LOL
Patrice
session ?
Est- ce que tu n'aurais pas une propriété "Shared" ou "Static" quelque part
(auquel cas elle sera partagée par tous les utilisateurs).
Patrice
--
"Norm" <No...@Norm.com> a écrit dans le message de
news:O52Jzy8V...@TK2MSFTNGP12.phx.gbl...
Norm
Je vais regarder avec mes compagnons de travail:
je retiens quand meme un point
Personally I would only limit myself to the session object nightmare when
1. cookies don't matter
2. deployed for a very limited environment
le point 2 c'est exactement notre cas, un Intranet. Donc, je ne bannirais
pas tout de suite les variables sessions, mais je continue de chercher une
façon de bien gérer tout ca.
Merci!
Norm
"Michel Thiffault" <mt...@h.ot_m.ai_l.com> a écrit dans le message de
news:eb3n1dGW...@tk2msftngp13.phx.gbl...
Norm
"Patrice" <nob...@nowhere.com> a écrit dans le message de
news:OuboOkGW...@TK2MSFTNGP09.phx.gbl...
> Normalement pas de soucis. Qu'est que tu stockes dans tes variables de
> session ?
des dataset et objet sérilalisé.
> Est- ce que tu n'aurais pas une propriété "Shared" ou "Static" quelque
part
> (auquel cas elle sera partagée par tous les utilisateurs)
Négatif.
Patrice
Patrice
--
"Norm" <No...@Norm.com> a écrit dans le message de
news:OSAE3xGW...@tk2msftngp13.phx.gbl...
Norm
d'un Intranet, et un utilisateur peut ouvrir plus d'un internet explorer
pour travailler dans l'intranet. L'idée de restreindre à un seul i.e par
utilsateur est impensable.
"Patrice" <nob...@nowhere.com> a écrit dans le message de
news:O516HCHW...@TK2MSFTNGP10.phx.gbl...
Patrice
fenêtres ?
A priori :
- si la deuxième fenêtre est ouverte à partir de l'instance existante d'IE,
c'est la même session
- si la deuxième fenêtre est ouverte en double cliquant sur l'icône d'IE, ce
sera une nouvelle instance d'IE et une nouvelle session
Difficile à dire sans le contexte exact, mais si les utilisateurs ont besoin
de se connecter en même temps sous des comptes différents, j'aurais tendance
à voir si cela ne serait pas à intégrer dans l'application. Dans les
messageries, il est généralement possible de donner des droitds à d'autre
utilisateurs sur une boîte pour qu'ils puissent agir au nom d'un
utilisateur. A priori ils peuvent faire cela sans se
déconnecter/reconnecter.
Patrice
--
"Norm" <No...@Norm.com> a écrit dans le message de
news:OcHYkwHW...@TK2MSFTNGP10.phx.gbl...
Michel Thiffault
sera dans la même session ou non. Avant IE 5.5 il y avait une configuration
possible à cet effet: lancer les nouvelles fenêtre dans le même "process"
(désolé, je ne me souviens pas de la dernière fois où j'ai utilisé Windows
en français). Nous pouvions ainsi garantir que les sessions étaient
utilisées dans toutes les fenêtres. Depuis IE 5.5 Windows décide si les
fenêtre sont lancées dans le même process ou non (selon les ressources
disponibles si je ne m'abuse).
Patrice wrote:
> L'utilisateur doit-il se connecter sous un compte différent dans les
> deux fenêtres ?
>
> A priori :
> - si la deuxième fenêtre est ouverte à partir de l'instance existante
> d'IE, c'est la même session
> - si la deuxième fenêtre est ouverte en double cliquant sur l'icône
> d'IE, ce sera une nouvelle instance d'IE et une nouvelle session
>
> Difficile à dire sans le contexte exact, mais si les utilisateurs ont
> besoin de se connecter en même temps sous des comptes différents,
> j'aurais tendance à voir si cela ne serait pas à intégrer dans
> l'application. Dans les messageries, il est généralement possible de
> donner des droitds à d'autre utilisateurs sur une boîte pour qu'ils
> puissent agir au nom d'un utilisateur. A priori ils peuvent faire
> cela sans se déconnecter/reconnecter.
>
> Patrice
>
>
Norm
> A priori :
> - si la deuxième fenêtre est ouverte à partir de l'instance existante
d'IE,
> c'est la même session
Dans notre cas, pour ouvrir "L'intranet" les utilisateurs cliquent sur un
raccourci créer sur leur bureau. Donc, la majorité du temps, les sessions ne
sont pas les mêmes dû au fait qu'ils ouvrent une nouvelle instance d'IE
> - si la deuxième fenêtre est ouverte en double cliquant sur l'icône d'IE,
ce
> sera une nouvelle instance d'IE et une nouvelle session
C'est bien là le problème, c'est pas toujours le cas.
>
> Difficile à dire sans le contexte exact, mais si les utilisateurs ont
besoin
> de se connecter en même temps sous des comptes différents, j'aurais
tendance
> à voir si cela ne serait pas à intégrer dans l'application. Dans les
> messageries, il est généralement possible de donner des droitds à d'autre
> utilisateurs sur une boîte pour qu'ils puissent agir au nom d'un
> utilisateur. A priori ils peuvent faire cela sans se
> déconnecter/reconnecter.
les utilisateurs utilisent un seul et meme compte.
Merci de votre aide
Norm
"Michel Thiffault" <mt...@h.ot_m.ai_l.com> a écrit dans le message de
news:eO3JjjRW...@TK2MSFTNGP10.phx.gbl...
> À ce que je sache il est impossible d'être certain qu'une nouvelle fenêtre
> sera dans la même session ou non. Avant IE 5.5 il y avait une
configuration
> possible à cet effet: lancer les nouvelles fenêtre dans le même "process"
> (désolé, je ne me souviens pas de la dernière fois où j'ai utilisé Windows
> en français). Nous pouvions ainsi garantir que les sessions étaient
> utilisées dans toutes les fenêtres. Depuis IE 5.5 Windows décide si les
> fenêtre sont lancées dans le même process ou non (selon les ressources
> disponibles si je ne m'abuse).
C'est la conclusion à laquelle j'arrive également.
http://support.microsoft.com/?kbid=240928
Si l'ordinateur dispose de moins de 32 mégaoctets (Mo) de mémoire vive, ce
paramètre est désactivé et toutes les instances d'Internet Explorer
partagent le même processus. Si l'ordinateur présente 32 Mo de RAM ou plus,
le paramètre est activé et les nouvelles instances d'Internet Explorer
génèrent la création de nouveaux processus.
Merci de votre aide.
Je trouve une façon de contourner le problème de session etje vous en fait
part.
Patrice
est le problème posé par le fait que la session est la même dans les deux
fenêtres ?
Je ne vois guère comme problème que d'utiliser un même nom pour deux usages
différents. Par exemple si on met en cache les données toujours sous le même
nom "MesDonnéesEnCache" cela posera problème. Par contre si l'on utilise
"Annuaire" d'une part et "Pays" d'autre part, les deux pages utiliseront
chacune la donnée en cache qui l'intéresse sans se marcher sur les pieds
?????
Patrice
--
"Norm" <No...@Norm.com> a écrit dans le message de
news:%23i28oyR...@TK2MSFTNGP10.phx.gbl...
>
[coupé]
>
> les utilisateurs utilisent un seul et meme compte.
>
[coupé]
Norm
quel
> est le problème posé par le fait que la session est la même dans les deux
> fenêtres ?
Supposons que l'utilisateur veut créer une facture dans la fenetre 1. et
dans la fenetre 2, il veut créer une autre facture.
Les deux fenetres utilisent la meme page .aspx. lorsque je saverais dans la
fenetre 2, les données serait mélangées avec la fenêtre1.
un exemple aprmis tant d'autres qui arrivent plus que fréquemment.
>Je ne vois guère comme problème que d'utiliser un même nom pour deux usages
>différents. Par exemple si on met en cache les données toujours sous le
même
>nom "MesDonnéesEnCache" cela posera problème. Par contre si l'on utilise
>"Annuaire" d'une part et "Pays" d'autre part, les deux pages utiliseront
>chacune la donnée en cache qui l'intéresse sans se marcher sur les pieds
Et que faites vous du cas que c'est la même page dans les deux applications.
Annuaire dans un et Annuaire dans l'autre dans ce cas.
C'est pourquoi l'option envisagée sera propablement de concaténé une
date(date ouverture de la page) dans le nom des variables sessions. Ainsi,
pour une meme session, chaque aurait ses variables sessions qui lui sont
propres.
Patrice
mélange peut intervenir :
- les données saisies dans la page 2 sont "postées" vers le serveur lorsque
la page est validée. Les données saisies dans la page 1 ne seront absolument
pas envoyés vers le serveur lors de la validation de la page 2 donc pas de
mélange.
Dans le cas 2, si les deux pages utilisent la même "source", il est au
contraire souhaitable qu'elles utilisent la même liste (le but recherché
étant bien d'extraire la liste une fois pour toute). La liste est bien la
même en toute circonstance (l'exemple d'une liste de pays est peut-être plus
pertinent). Par contre si cette annuaire est utilisé dans un but totalement
différent (avec des filtres etc ???), il faudrait effectivement plusieurs
variables (ou ne pas cacher si cela varie de toute façon).
Si des variables de session sont utilisés transitoirement dans le traitement
des pages, je rejoins avec modération l'avis de Michel. Les variables de
session ne sont pas mauvaises en soi mais peuvent effectivement poser
problème selon la façon dont on les utilise (notamment si elles sont
utilisées pour "cacher" des données en lecture/écriture ou par exemple pour
passer des données d'une page à l'autre). Décrit éventuellement leur usage
si tu souhaites continuer la conversation (par exemple tu en as quand tu
valides une facture ?)
De mon côté, j'en ai une poignée essentiellement utilisées pour mémoriser
les caractéristiques essentielles du "profil" de l'utilisateur en cours.
Sinon j'utilise plutôt le cache pour des données essentiellement en lecture
seule qui sont d'ailleurs partagées par tous les utilisateurs plutôt que
pour un utilisateur particulier sur une certaine période. De mémoire, je
cache rarement voire jamais les données au niveau d'un utilisateur unique.
Patrice
--
"Norm" <No...@Norm.com> a écrit dans le message de
news:%23h5xX2S...@TK2MSFTNGP12.phx.gbl...
Norm
> Pour l'exemple des factures je ne vois pas toujours pas trop comment le
> mélange peut intervenir :
> - les données saisies dans la page 2 sont "postées" vers le serveur
lorsque
> la page est validée. Les données saisies dans la page 1 ne seront
absolument
> pas envoyés vers le serveur lors de la validation de la page 2 donc pas de
> mélange.
validation de la page 2.
Mais lors de cette même validation si je vais chercher des données dans la
session, alors là oui il va chercher les variables sessions de la page 1
lorsque c'est la même session.
> Si des variables de session sont utilisés transitoirement dans le
traitement
> des pages, je rejoins avec modération l'avis de Michel. Les variables de
> session ne sont pas mauvaises en soi mais peuvent effectivement poser
> problème selon la façon dont on les utilise (notamment si elles sont
> utilisées pour "cacher" des données en lecture/écriture ou par exemple
pour
> passer des données d'une page à l'autre). Décrit éventuellement leur usage
> si tu souhaites continuer la conversation (par exemple tu en as quand tu
> valides une facture ?)
C'est justement ce que je me rends compte que c'est pas viable à cause du
partage de session.
Voyons le pourquoi je garde ça en session.
Supposons que j'ai dix lignes (dans un datagrid) de factures créer pour la
premiere facture, mais qu'elles ne sont pas sauvegardés encore.
Comment faire pour garder ces lignes entre chaque postback.
Ce que je fais c'est de garder un dataset en session et de le réaffecter au
datasource du datagrid au besoin, par exemple apres un edit d'une ligne du
datagrid.
-Solution envisagés : Garder le dataset dans le viewstate. (mauvais car
augmente la grosseur de la page apsx)
Garder en session(mauvais car sessions
partagées, d'où mon post)
Norm
dans un champ texte caché dans le page load.
If IsNothing(txtDateSession.Text = "") Then
txtDateSession.Text = Now.ToString
End If
et de concaténer cette date dans le nom des variables session.
ex: session("Test" & txtDateSession.text ) = "Blablabla"
On s'assure bien de n'avoir des variables uniques par navigateur
Si des variables session peuvent etre partagés sans probleme alors pas
nécessaire de concaténé bien entendu.
"Norm" <No...@Norm.com> a écrit dans le message de
news:%23dvHa0R...@TK2MSFTNGP11.phx.gbl...
Michel Thiffault
> Si des variables de session sont utilisés transitoirement dans le
> traitement des pages, je rejoins avec modération l'avis de Michel.
J'admet avoir un point de vue extrême sur les variables sessions. Disons que
lorsque nos applications ont commencé à être utilisées par quelques milliers
d'utilisateur nous avons dû repasser tous le code pour les remplacer pour
être compatible avec des web farms (pas agréable du tout!).
Pour en revenir au problème de notre collègue Norm il semble que le
viewstate devient de plus en plus intéressant dans son cas.
Patrice
- un RegisterHiddenField pour créer un champ caché, ce champ est
System.NewGuid
- la variable de session est crée avec un préfixe et ce System..NewGuid
Chaque page peut donc avoir sa propre variable de session.
Il est aussi possible de voir selon le contexte exact (complexité/temps
passé par l'utilisateur) :
- sauver les données dans une facture "non validée peut-être intéressant
(permet par exemple d'abandonner puis de reprendre ultérieurement)
- certes en abandonnant la datagrid, il serait possible de mener toute la
saisie sur le client (en ajoutant une ligne à chaque saisie dans la ligne de
saisie). La tableau de saisie s'étend et les données sont toutes récupérées
au postback final.
Patrice
--
"Norm" <No...@Norm.com> a écrit dans le message de
news:OkjrfWU...@TK2MSFTNGP11.phx.gbl...
>
[coupé]
Patrice
reconnecter.
Le boiter de "load balancing" (Altéon) est capable de diriger une requête
toujours vers le même serveur (plusieurs méthodes sont possible, IP, cookie
etc...).
Nos sites Web ont également moins d'utilisateurs (applications verticales
voire spécifique à un projet).
Patrice
--
"Michel Thiffault" <mt...@h.ot_m.ai_l.com> a écrit dans le message de
news:%23JZsNYV...@TK2MSFTNGP09.phx.gbl...