Discussion :

[narfight]

Bonjour tout le monde,

Je travail avec des variables de session pour passer entre deux pages des informations.

J'ai créer une fonction pour centraliser mes redirections avec message que j'apelle ainsi :

Code :

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

Utility.RedirectionWithText(Page, "~/test/", "Votre demande a bien été envoyée", "Confirmation");

et voici monde code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Utility
{
    public Utility()
    {
 
    }
 
    static public void RedirectionWithText(Page Page, string url)
    {
        Page.Session.Add("Redirect-URL", Page.ResolveUrl(url));
        Page.Response.Redirect(Page.ResolveUrl("~/Ok.aspx"));
    }
}

Si je fais un break juste avant le Page.response.redirection(...), je vois que ma session à bien le "Redirect-URL" mais quand je suis sur la page ~/Ok.aspx, je vois correctemen ma session sauf que "Redirect-URL" n'est pas présent. C'est comme si je travaillais sur une copie de ma session quand je le passe en paramètre alors que le c# travail avec une sorte de pointeur non ?

J'ai tenté d'utiliser HttpContext.Current.Session à la place de Page.Session mais le résultat est le même.

Pouvez-vous me dire si je dois faire une sorte de Session.Save() pour forcer la sauvegarde de la session où alors il faut revoir toute ma méthodologie ?

Merci d'avance

[g_tarik0010]

Essaye plutot avec HttpContext.Current.Session.Add("taclé", "tavaleur");

[narfight]

J'ai tenté cette solution mais elle donne le même résultat

[Bluedeep]

Je ne suis pas du tout un pro de asp.net mais essaye de mettre un break point sur l'event de fin de session dans le global.asax et vérifie que tu n'y passes pas.

[narfight]

Quand j'arrive sur ma 2éme page, j'ai encore toutes les autres var de session qui sont déclarées à l'ouverture de session dans le global.asax. Il ne cloture donc pas ma session.

C'est vraiment juste la var ajoutée par ma classe Utility.

Quand je fais un break juste avant le "Page.Response". J'ai bien l'enssemble des variables de session au complet mais il semble ne pas sauvegarder les derniéres modification.

Merci pour toutes ces pistes !

[Nathanael Marchand]

Il faut bien comprendre le mécanisme des sessions.
Les sessions ca se base sur les cookies. Quand tu mets quelque chose en session il y a donc un cookie qui est crée chez le client. Or la création de ce cookie se fait via les header de la réponse http. Ce qui se passe ici, c'est qu'en envoyant un Redirect, il envoie une réponse de http 302 de redirection mais cette réponse soit elle ne contient pas le setcookie ou alors il n'est pas interprété par le navigateur (je sais plus trop en détails).
Conclusion, si tu settes qqchose, ne fait pas de redirect juste derrière.

[narfight]

Mais le cookies ne comporte que l'ID de session non ? Donc si je demande à l'ASP de modifier des informations sur la session, cette modification sera réalisé coté serveur. le cookies ne devrait du coup pas changer de valeur.

J’avoue avoir lut dans le MSDN qu’il stockait coté client les informations mais quand je regarde le contenu de mon cookies je me dis qu’il ne stocke que l’ID :


Je joins par sécurité ma config pour la session :

Code :

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

<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="InProc" timeout="60"/>

[Bluedeep]

Il faut bien comprendre le mécanisme des sessions.
Les sessions ca se base sur les cookies. Quand tu mets quelque chose en session il y a donc un cookie qui est crée chez le client.

Euh, sauf erreur de ma part, (mes souvenirs asp.net sont lointains) ce n'est pas tout à fait cela. Les sessions se basent sur les cookies, ok (encore que ce ne soit pas obligatoire, on peut utiliser des sessions "cookieless"), mais les variables de session n'ont rien à voir avec les cookies (sinon, il n'y aurait pas nécessité à les persister au niveau du load-balancing).

D'ailleurs les variables de sessions ne sont pas transmises au client, contrairement au viewstate.

[Nathanael Marchand]

Euh, sauf erreur de ma part, (mes souvenirs asp.net sont lointains) ce n'est pas tout à fait cela. Les sessions se basent sur les cookies, ok (encore que ce ne soit pas obligatoire, on peut utiliser des sessions "cookieless"), mais les variables de session n'ont rien à voir avec les cookies (sinon, il n'y aurait pas nécessité à les persister au niveau du load-balancing).

D'ailleurs les variables de sessions ne sont pas transmises au client, contrairement au viewstate.

Effectivement c'est pas assez détaillé de ma part. C'est l'identifiant qui est dans le cookie. Le plus simple c'est de regarder avec Fiddler sans le Redirect puis avec le Redirect si il y a une différence.

[narfight]

J'ai trouvé le pourquoi mais pas encore le comment !

IE9 refuse mon cookie de session qui ne comporte que l'ID (pour information). Il relance donc à chaque page une nouvelle session et perd mes données.

Je vous tiens au courrant au cas où quelqu'un aurrait le même problème

[narfight]

Bon suite a un reset des params de IE9, tout est revenu à la normal

Merci à vous tous pour votre aide.