ASP.NET : Session.SessionID change entre les requêtes

Question

Pourquoi la propriété SessionID sur le Session L'objet d'une page ASP.NET change-t-il d'une requête à l'autre ?

J'ai une page comme celle-ci :

...
<div>
    SessionID: <%= SessionID %>
</div>
...

Et la sortie change à chaque fois que j'appuie sur F5, indépendamment du navigateur.

Answer 1

C'est la raison pour laquelle

Lorsqu'il utilise un état de session basé sur les cookies, ASP.NET n'alloue pas de stockage pour les données de session avant que l'objet Session ne soit utilisé. Par conséquent, un nouvel ID de session est généré pour chaque demande de page jusqu'à ce que l'objet Session soit utilisé. Si votre application nécessite un ID de session statique pour l'ensemble de la session, vous pouvez soit implémenter la méthode Session_Start dans le fichier Global.asax de l'application et stocker des données dans l'objet Session pour fixer l'ID de session, soit utiliser du code dans une autre partie de votre application pour stocker explicitement des données dans l'objet Session.

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.httpsessionstate.sessionid.aspx

Ainsi, à moins que vous n'accédiez à votre objet de session dans le backend, un nouvel identifiant de session sera généré à chaque requête.

EDITAR

Ce code doit être ajouté dans le fichier Global.asax. Il ajoute une entrée à l'objet Session pour que vous fixiez la session jusqu'à son expiration.

protected void Session_Start(Object sender, EventArgs e) 
{
    Session["init"] = 0;
}

Answer 2

Il existe une autre raison, plus insidieuse, pour laquelle cela peut se produire même lorsque l'objet Session a été initialisé, comme le montre Cladudio.

Dans le Web.config, s'il y a un fichier <httpCookies> qui a pour valeur requireSSL="true" mais vous n'utilisez pas réellement HTTPS : pour une requête spécifique, alors le cookie de session n'est pas envoyé (ou peut-être pas renvoyé, je ne suis pas sûr) ce qui signifie que vous vous retrouvez avec une toute nouvelle session pour chaque requête.

Je l'ai découvert à la dure, en passant plusieurs heures à faire des allers-retours entre plusieurs commits dans mon contrôle de source, jusqu'à ce que je trouve quel changement spécifique avait cassé mon application.

Answer 3

Dans mon cas, j'ai découvert que le cookie de session avait une valeur de domaine qui comprenait www. préfixe, alors que je demandais une page sans www. .
Ajout de www. à l'URL a immédiatement réglé le problème. Plus tard, j'ai changé le domaine du cookie pour qu'il soit défini sur .mysite.com au lieu de www.mysite.com .

Answer 4

En utilisant la réponse de Neville (en supprimant requireSSL = true, dans web.config) y En modifiant légèrement le code de Joel Etherton, voici le code qui devrait gérer un site fonctionnant à la fois en mode SSL et en mode non SSL, en fonction de l'utilisateur et de la page (je me replonge dans le code et je ne l'ai pas encore testé sur SSL, mais je pense qu'il devrait fonctionner - je serai trop occupé plus tard pour y revenir, alors le voici :

if (HttpContext.Current.Response.Cookies.Count > 0)
        {
            foreach (string s in HttpContext.Current.Response.Cookies.AllKeys)
            {
                if (s == FormsAuthentication.FormsCookieName || s.ToLower() == "asp.net_sessionid")
                {
                    HttpContext.Current.Response.Cookies[s].Secure = HttpContext.Current.Request.IsSecureConnection;
                }
            }
        }

Answer 5

Mon problème concernait une application IPTV Microsoft MediaRoom. Il s'avère que les applications MPF MRML ne prennent pas en charge les cookies ; le fait de changer pour utiliser des sessions sans cookies dans le web.config a résolu mon problème.

<sessionState cookieless="true"  />

Voici un VRAI vieil article à ce sujet : ASP.NET sans cuisson