ASP.NET: Session.SessionID cambia tra le richieste

Perché la proprietà SessionID sulla sessione -oggetto in un cambiamento ASP.NET-page tra le richieste?

Ho una pagina come questa:

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

E l'output continua a cambiare ogni volta che premo F5, indipendentemente dal browser.

Questo è il motivo

Quando si utilizza lo stato della sessione basato su cookie, ASP.NET non alloca l'archiviazione per i dati della sessione fino a quando non viene utilizzato l'oggetto Session. Di conseguenza, viene generato un nuovo ID sessione per ogni richiesta di pagina fino all'accesso all'oggetto sessione. Se l'applicazione richiede un ID sessione statica per l'intera sessione, è possibile implementare il metodo Session_Start nel file Global.asax dell'applicazione e archiviare i dati nell'oggetto Session per correggere l'ID sessione, oppure è possibile utilizzare il codice in un'altra parte del applicazione per memorizzare esplicitamente i dati nell'oggetto Session.

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

Quindi, fondamentalmente, a meno che non si acceda all'oggetto sessione sul back-end, verrà generato un nuovo ID sessione con ogni richiesta

MODIFICARE

Questo codice deve essere aggiunto al file Global.asax. Aggiunge una voce all'oggetto Session in modo da correggere la sessione fino alla scadenza.

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

C'è un'altra ragione, più insidiosa, per cui ciò può accadere anche quando l'oggetto Session è stato inizializzato, come dimostrato da Cladudio.

Nel Web.config, se esiste una <httpCookies>voce impostata requireSSL="true"ma non si sta effettivamente utilizzando HTTPS: per una richiesta specifica, il cookie di sessione non viene inviato (o forse non restituito, non sono sicuro di quale) che significa che si finisce con una nuova sessione per ogni richiesta.

Ho trovato questo nel modo più difficile, trascorrendo diverse ore andando avanti e indietro tra diversi commit nel mio controllo del codice sorgente, fino a quando ho scoperto quale modifica specifica aveva rotto la mia applicazione.

Nel mio caso ho capito che il cookie di sessione aveva un dominio che includeva il www.prefisso, mentre richiedevo la pagina con no www..
L'aggiunta www.all'URL risolve immediatamente il problema. Successivamente ho modificato il dominio dei cookie per essere impostato su .mysite.comanziché www.mysite.com.

il mio problema era che avevamo questo set in web.config

<httpCookies httpOnlyCookies="true" requireSSL="true" />

ciò significa che durante il debug in non SSL (impostazione predefinita), il cookie di autenticazione non verrebbe inviato di nuovo al server. ciò significherebbe che il server invierebbe un nuovo cookie di autenticazione (con una nuova sessione) per ogni richiesta al client.

la correzione è impostare requiressl su false in web.config e true in web.release.config o attivare SSL durante il debug:

Utilizzando la risposta di Neville (eliminando requestSSL = true, in web.config) e modificando leggermente il codice di Joel Etherton, ecco il codice che dovrebbe gestire un sito che funziona sia in modalità SSL che non SSL, a seconda dell'utente e della pagina (I sto tornando indietro nel codice e non l'ho ancora testato su SSL, ma mi aspetto che dovrebbe funzionare - sarà troppo occupato in seguito per tornare a questo, quindi eccolo qui:

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;
                }
            }
        }

Un'altra possibilità che causa la modifica dell'ID sessione tra le richieste, anche quando Session_OnStart è definito e / o è stata inizializzata una sessione, è che l'URL hostname contiene un carattere non valido (come un carattere di sottolineatura). Credo che questo sia specifico di IE (non verificato), ma se il tuo URL è, diciamo http://server_name/app, allora IE bloccherà tutti i cookie e le informazioni sulla tua sessione non saranno accessibili tra le richieste.

In effetti, ogni richiesta genererà una sessione separata sul server, quindi se la tua pagina contiene più immagini, tag di script, ecc., Ognuna di quelle richieste GET si tradurrà in una sessione diversa sul server.

Ulteriori informazioni: http://support.microsoft.com/kb/316112

Nel mio caso questo stava accadendo molto nei miei ambienti di sviluppo e test. Dopo aver provato tutte le soluzioni di cui sopra senza successo, ho scoperto che ero in grado di risolvere questo problema eliminando tutti i cookie di sessione. L'estensione per gli sviluppatori Web lo rende molto semplice. Uso principalmente Firefox per test e sviluppo, ma ciò è accaduto anche durante i test su Chrome. La correzione ha funzionato anche in Chrome.

Non ho ancora dovuto farlo nell'ambiente di produzione e non ho ricevuto segnalazioni di persone che non erano in grado di accedere. Anche questo sembrava accadere solo dopo aver reso sicuri i cookie di sessione. Non è mai successo in passato quando non erano sicuri.

nel mio caso era perché stavo modificando la sessione dopo il reindirizzamento da un gateway in un'applicazione esterna , quindi perché stavo usando IP invece su localhost in quell'URL di quella pagina era in realtà considerato un sito Web diverso con sessioni diverse.

In sintesi

prestare maggiore attenzione se si sta eseguendo il debug di un'applicazione ospitata su IIS anziché IIS express e mescolando la macchina http: // Ip e http: // localhost in varie pagine

Il mio problema era con un'applicazione IPTV di Microsoft MediaRoom. Si scopre che le applicazioni MPML MRML non supportano i cookie; cambiando per usare sessioni senza cookie nel web.config ha risolto il mio problema

<sessionState cookieless="true"  />

Ecco un articolo DAVVERO al riguardo: ASP.NET senza cucina

Sono su .NET Core 2.1 e sono ben consapevole che la domanda non riguarda Core. Eppure manca internet e Google mi ha portato qui sperando così di salvare qualcuno qualche ora.

Startup.cs

services.AddCors(o => o.AddPolicy("AllowAll", builder =>
            {
                builder
                    .WithOrigins("http://localhost:3000")     // important
                    .AllowCredentials()                       // important
                    .AllowAnyMethod()
                    .AllowAnyHeader();       // obviously just for testing
            }));

client.js

const resp = await fetch("https://localhost:5001/api/user", {
            method: 'POST',
            credentials: 'include',                           // important
            headers: {
                'Content-Type': 'application/json'
            },
            body: JSON.stringify(data)
        })

Controllers/LoginController.cs

namespace WebServer.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class UserController : ControllerBase
    {
        [HttpPost]
        public IEnumerable<string> Post([FromBody]LoginForm lf)
        {
            string prevUsername = HttpContext.Session.GetString("username");
            Console.WriteLine("Previous username: " + prevUsername);

            HttpContext.Session.SetString("username", lf.username);

            return new string[] { lf.username, lf.password };
        }
    }
}

Si noti che la sessione di scrittura e lettura funziona, tuttavia non sembrano essere passati cookie al browser. Almeno non sono riuscito a trovare un'intestazione "Set-Cookie" da nessuna parte.

Questo stava cambiando per me a partire da .NET 4.7.2 ed era dovuto alla proprietà SameSite sul cookie di sessione. Vedi qui per maggiori informazioni: https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/

Il valore predefinito è cambiato in "Lax" e ha iniziato a rompere le cose. L'ho cambiato in "Nessuno" e le cose hanno funzionato come previsto.

Assicurati di non avere un timeout di sessione molto breve e assicurati anche che se stai utilizzando sessioni basate su cookie, accetti la sessione.

FireFox webDeveloperToolbar è utile in momenti come questo in quanto puoi vedere i cookie impostati per la tua applicazione.

Il ripristino dell'ID sessione può avere molte cause. Tuttavia, quanto sopra menzionato non riguarda il mio problema. Quindi lo descriverò per riferimento futuro.

Nel mio caso una nuova sessione creata su ogni richiesta ha comportato un ciclo di reindirizzamento infinito. L'azione di reindirizzamento ha luogo nell'evento OnActionExecuting .

Inoltre ho cancellato tutte le intestazioni http (anche nell'evento OnActionExecuting utilizzando il metodo Response.ClearHeaders ) per impedire la memorizzazione nella cache dei siti sul lato client. Ma questo metodo cancella tutte le intestazioni, comprese le informazioni sulla sessione dell'utente, e di conseguenza tutti i dati nella memoria temporanea (che stavo usando più avanti nel programma). Quindi anche l'impostazione di una nuova sessione nell'evento Session_Start non ha aiutato.

Per risolvere il mio problema, mi sono assicurato di non rimuovere le intestazioni quando si verifica un reindirizzamento.

Spero che aiuti qualcuno.

Ho riscontrato questo problema in un modo diverso. I controller che avevano questo attributo [SessionState(SessionStateBehavior.ReadOnly)]stavano leggendo da una sessione diversa anche se avevo impostato un valore nella sessione originale all'avvio dell'app. Stavo aggiungendo il valore della sessione tramite _layout.cshtml (forse non è la migliore idea?)

È stato chiaramente il ReadOnly a causare il problema perché quando ho rimosso l'attributo, la sessione originale (e SessionId) sarebbero rimasti in contatto. L'utilizzo della soluzione di Claudio / Microsoft l'ha risolto.