Discussion :

[Webman]

Salut,

J'ai constaté ce qui me semble être un problème (bug ? normal ?) dans Visual Studio .Net. Dans une page ASPX, quand je crée un lien vers une autre page, si le lien est relatif au document alors ma session est conservée, si le lien est relatif à la racine (de l'appli) alors ma session est perdue...

Je m'explique:

J'ai une page A dont l'url est :
http://localhost/mon_appli/(dhsfds54f5x5s)/ma_pageA.aspx

Si j'utilise depuis cette page un lien relatif au document vers une page B alors le lien va pointer vers:
http://localhost/mon_appli/(dhsfds54f5x5s)/ma_pageB.aspx
Là tout est normal.

Par contre si j'utilise un lien relatif à la racine, le lien vers ma page B va pointer vers:
http://localhost/mon_appli/ma_pageB.aspx
Et là j'ai perdue ma session , et bien sûr ca c'est pas possible , j'en ai besoin de ma session !

Quelqu'un à déjà été confronté à ce problème ? quelqu'un à une solution ?
Bon en même temps je sais bien puisque mon lien est relatif à la racine, le lien débute avant l'emplacement de la session dans l'URL, alors que dans le cas du lien relatif au document le lien part aprés l'emplacement de la session dans l'URL... mais bon quand même c'est pas top...

Je suis donc à la recherche d'une solution, car du fait une j'utilise un controle web utilisateur se trouvant à différents niveaux dans l'arbo de répertoires j'aurais besoin d'utiliser des liens relatifs à la racine... sinon je vais être obligé de créer un controle web utilisateur par niveau de répertoire dans l'arbo... .

Si vous n'avez pas tout compris (pas facile à expliquer clairement ) n'hésitez pas à me demander des précisions.

Merci d'avance pour vos suggestions

[Webman]

Personne pour m'aider C'est pas gentil tout ca

[Pasiphae]

Bonsoir.

Je n ai pas du tout l habitude d utiliser les sessions, mais je vais quand meme me permettre une suggestion.

Est ce que tu ne pourrais pas stocker l identifiant de la session dans un objet (application, cache, session) et lorsque tu as besoin de faire un lien relatif a la racine (je suppose que tu utilises : ~), de faire une fonction qui redefinit ton url en incorporant le numero de session ?

Sinon dans l objet HttpContext.Current il n y aurait quelque chose pour recuperer l id de session (sessionid) ?

Faire un truc du genre :

Code :

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

1
2
3
 
String redirection = "~/Rep1/"+ HttpContext.Current.Session.SessionID + "/Ici.aspx";
Response.Redirect(redirection);

???

Je n ai pas d autres idées.
Bon courage.

[Maniak]

http://localhost/mon_appli/(dhsfds54f5x5s)/ma_pageA.aspx

Tu utilises visiblement le mode cookieless des sessions. Manque de bol, c'est évidemment dépendant de l'uri. Alors tant que tu utilises des liens relatifs, nickel, ça trouve toujours l'identifiant de la session. Un lien absolu zappe tout, donc fatalement, y a plus.

Alors au choix :
- passe dans un autre mode de session (dans tous les cas, les cookies devront être activés)
- n'utilise pas l'objet session et débrouille-toi sans (généralement en passant par des cookies toi-même)
- fais passer tous tes liens par une moulinette qui intercale l'identifiant de la session dans les liens absolus.

[Ditch]

Il y a encore un autre mode (j'ai oublié le nom) qui permet de stocker ces sessions dans une base de données sqlServer et cela automatiquement (pas besoin de faire des accés explicites)

[Maniak]

Il y a encore un autre mode (j'ai oublié le nom) qui permet de stocker ces sessions dans une base de données sqlServer et cela automatiquement (pas besoin de faire des accés explicites)

Ainsi que le mode state server. Mais ça passe de toute façon par un cookie.

En cookieless, l'identifiant de session est dans l'uri.
Dans les 3 autres modes, il est dans un cookie.

En mode InProc, les données sont en mémoire sur le serveur, dans le processus de l'appli (dans IIS quoi). On les perd si on recompile l'application et elles dépendent d'une seule machine.

En mode StateServer, elles sont en mémoire, dans le processus du service ASP.NET State Service qui peut être sur une autre machine. On ne les perd pas en recompilant mais elles dépendent toujours d'une seule machine. C'est plus lent qu'InProc, mais pas monstrueux.

En mode SQLServer, elles sont sur un serveur SQL, qui peut être n'importe où, notamment en cluster. On ne les perd pas en recompilant, elles ne dépendent pas forcément d'une seule machine (clustering donc), mais c'est le plus lent des modes.


Dans tous les cas, ça colle donc un cookie avec l'identifiant de session, et l'activation des sessions empêche l'exécution simultanée de plusieurs pages pour une même session. Ce qui n'est pas le cas si on n'abuse pas des variables de session et qu'on peut se débrouiller soi-même avec des cookies 'faits maison'. Bref, si on peut s'en passer, faut pas hésiter :)

[Webman]

Merci à vous tous pour ces explications détaillées. Je comprends maintenant pourquoi je ne récupère pas ma session dans mon URI en cas d'utilisation de liens relatifs à la racine.

Ayant quelques impératifs en terme de délais je vais utiliser trois contrôles utilisateurs pour mes trois niveaux d'arbo de répertoires, ca ne me prendra qu'une petite heure... Je reconnaît que c'est du bricolage à deux francs... mais c'est le plus rapide dans ma situation... Par la suite faudra que j'envisage sérieusement l'emploi de cookies... enfin ca sera pour les évolutions suivantes.

Encore une fois, merci beaucoup .