ASP.NET_SessionId + OWIN I cookie non vengono inviati al browser

Ho uno strano problema con l'utilizzo dell'autenticazione con cookie Owin.

Quando avvio il mio server IIS l'autenticazione funziona perfettamente su IE / Firefox e Chrome.

Ho iniziato a fare alcuni test con autenticazione e accesso su piattaforme diverse e ho riscontrato uno strano errore. Sporadicamente il framework Owin / IIS non invia alcun cookie ai browser. Digiterò un nome utente e una password corretti per l'esecuzione del codice ma nessun cookie viene consegnato al browser. Se riavvio il server inizia a funzionare, ad un certo punto proverò ad accedere e di nuovo i cookie non verranno più consegnati. Il passaggio sul codice non fa nulla e non genera errori.

 app.UseCookieAuthentication(new CookieAuthenticationOptions
        {
            AuthenticationMode = AuthenticationMode.Active,
            CookieHttpOnly = true,
            AuthenticationType = "ABC",
            LoginPath = new PathString("/Account/Login"),
            CookiePath = "/",
            CookieName = "ABC",
            Provider = new CookieAuthenticationProvider
               {
                  OnApplyRedirect = ctx =>
                  {
                     if (!IsAjaxRequest(ctx.Request))
                     {
                        ctx.Response.Redirect(ctx.RedirectUri);
                     }
                 }
               }
        });

E all'interno della mia procedura di accesso ho il seguente codice:

IAuthenticationManager authenticationManager = HttpContext.Current.GetOwinContext().Authentication;
                            authenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie);

var authentication = HttpContext.Current.GetOwinContext().Authentication;
var identity = new ClaimsIdentity("ABC");
identity.AddClaim(new Claim(ClaimTypes.Name, user.Username));
identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, user.User_ID.ToString()));
identity.AddClaim(new Claim(ClaimTypes.Role, role.myRole.ToString()));
    authentication.AuthenticationResponseGrant =
        new AuthenticationResponseGrant(identity, new AuthenticationProperties()
                                                   {
                                                       IsPersistent = isPersistent
                                                   });

authenticationManager.SignIn(new AuthenticationProperties() {IsPersistent = isPersistent}, identity);

Aggiornamento 1: sembra che una causa del problema sia quando aggiungo elementi alla sessione che iniziano i problemi. L'aggiunta di qualcosa di semplice come Session.Content["ABC"]= 123sembra creare il problema.

Quello che posso capire è il seguente: 1) (Chrome) Quando accedo ottengo ASP.NET_SessionId + il mio cookie di autenticazione. 2) Vado a una pagina che imposta un session.contents ... 3) Apri un nuovo browser (Firefox) e prova ad accedere e non riceve un ASP.NET_SessionId né riceve un cookie di autenticazione 4) Mentre il primo browser ha ASP.NET_SessionId continua a funzionare. Nel momento in cui rimuovo questo cookie ha lo stesso problema di tutti gli altri browser su cui sto lavorando su indirizzo IP (10.xxx) e localhost.

Aggiornamento 2:ASPNET_SessionId imponi la creazione della prima nella mia pagina login_load prima dell'autenticazione con OWIN.

1) prima di autenticarmi con OWIN faccio un casuale Session.Content valore sulla mia pagina di accesso per avviare ASP.NET_SessionId 2) quindi autentico e faccio ulteriori sessioni 3) Altri browser sembrano ora funzionare

Questo è bizzarro. Posso solo concludere che ciò ha a che fare con ASP e OWIN pensando che si trovino in domini diversi o qualcosa del genere.

Aggiornamento 3 - Strano comportamento tra i due.

Ulteriore strano comportamento identificato: il timeout della sessione Owin e ASP è diverso. Quello che sto vedendo è che le mie sessioni Owin rimangono in vita più a lungo delle mie sessioni ASP attraverso un meccanismo. Quindi quando eseguo l'accesso: 1.) Ho una sessione di autenticazione basata su cucinata 2.) Ho impostato alcune variabili di sessione

Le variabili della mia sessione (2) "muoiono" prima che la variabile della sessione del cookie owin imponga di nuovo il login, causando comportamenti imprevisti in tutta la mia applicazione. (La persona è loggata ma non è realmente loggata)

Aggiornamento 3B

Dopo alcuni scavi ho visto alcuni commenti su una pagina che affermano che il timeout di autenticazione dei "moduli" e il timeout della sessione devono corrispondere. Penso normalmente che i due siano sincronizzati, ma per qualsiasi motivo i due non sono sincronizzati.

Riepilogo delle soluzioni alternative

1) Crea sempre una sessione prima dell'autenticazione. Fondamentalmente creare una sessione quando si avvia l'applicazioneSession["Workaround"] = 0;

2) [Sperimentale] se si persistono i cookie assicurarsi che il timeout / lunghezza OWIN sia più lungo della sessioneTimeout nel web.config (in fase di test)

Ho riscontrato lo stesso problema e rintracciato la causa dell'implementazione di hosting ASP.NET OWIN. Direi che è un bug.

Qualche sfondo

Le mie scoperte si basano su queste versioni di assembly:

• Microsoft.Owin, Versione = 2.0.2.0, Cultura = neutro, PublicKeyToken = 31bf3856ad364e35
• Microsoft.Owin.Host.SystemWeb, Versione = 2.0.2.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35
• System.Web, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a

OWIN utilizza la propria astrazione per funzionare con i cookie di risposta ( Microsoft.Owin.ResponseCookieCollection ). Questa implementazione avvolge direttamente la raccolta delle intestazioni di risposta e aggiorna di conseguenza l'intestazione Set-Cookie . L'host ASP.NET OWIN ( Microsoft.Owin.Host.SystemWeb ) esegue il wrapping di System.Web.HttpResponse e la sua raccolta di intestazioni. Pertanto, quando viene creato un nuovo cookie tramite OWIN, rispondere Set-Cookie intestazione viene modificata direttamente.

Ma ASP.NET utilizza anche la propria astrazione per funzionare con i cookie di risposta. Questo ci viene esposto come proprietà System.Web.HttpResponse.Cookies e implementato dalla classe sigillata System.Web.HttpCookieCollection . Questa implementazione non racchiude direttamente l'intestazione Set-Cookie di risposta ma utilizza alcune ottimizzazioni e una manciata di notifiche interne per manifestare il suo stato modificato nell'oggetto risposta.

Quindi c'è un punto in ritardo nella durata della richiesta in cui viene testato lo stato modificato di HttpCookieCollection ( System.Web.HttpResponse.GenerateResponseHeadersForCookies () ) e i cookie vengono serializzati nell'intestazione Set-Cookie . Se questa raccolta si trova in uno stato specifico, l'intera intestazione Set-Cookie viene prima cancellata e ricreata dai cookie memorizzati nella raccolta.

L'implementazione della sessione ASP.NET utilizza la proprietà System.Web.HttpResponse.Cookies per archiviare il suo cookie ASP.NET_SessionId. Inoltre c'è qualche ottimizzazione di base nel modulo stato sessione ASP.NET ( System.Web.SessionState.SessionStateModule ) implementato attraverso la proprietà statica denominata s_sessionEverSet che si spiega da sé. Se hai mai archiviato qualcosa nello stato della sessione nella tua applicazione, questo modulo farà un po 'più di lavoro per ogni richiesta.

Torna al nostro problema di accesso

Con tutti questi pezzi i tuoi scenari possono essere spiegati.

Caso 1 - La sessione non è mai stata impostata

System.Web.SessionState.SessionStateModule , la proprietà s_sessionEverSet è falsa. Nessun ID sessione viene generato dal modulo stato sessione e lo stato della raccolta System.Web.HttpResponse.Cookies non viene rilevato come modificato . In questo caso i cookie OWIN vengono inviati correttamente al browser e il login funziona.

Caso 2: la sessione è stata utilizzata da qualche parte nell'applicazione, ma non prima che l'utente tentasse di autenticarsi

System.Web.SessionState.SessionStateModule , la proprietà s_sessionEverSet è vera. Gli ID sessione vengono generati da SessionStateModule , ASP.NET_SessionId viene aggiunto alla raccolta System.Web.HttpResponse.Cookies ma viene rimosso in seguito nella durata della richiesta poiché la sessione dell'utente è effettivamente vuota. In questo caso, lo stato della raccolta System.Web.HttpResponse.Cookies viene rilevato come modificato e l' intestazione Set-Cookie viene prima cancellata prima che i cookie vengano serializzati sul valore dell'intestazione.

In questo caso i cookie di risposta OWIN vengono "persi" e l'utente non viene autenticato e viene reindirizzato alla pagina di accesso.

Caso 3: la sessione viene utilizzata prima che l'utente tenti di autenticarsi

System.Web.SessionState.SessionStateModule , la proprietà s_sessionEverSet è vera. Gli ID sessione vengono generati da SessionStateModule , ASP.NET_SessionId viene aggiunto a System.Web.HttpResponse.Cookies . A causa dell'ottimizzazione interna in System.Web.HttpCookieCollection e System.Web.HttpResponse.GenerateResponseHeadersForCookies () L'intestazione Set-Cookie NON viene prima cancellata ma solo aggiornata.

In questo caso, sia i cookie di autenticazione OWIN che i cookie ASP.NET_SessionId vengono inviati in risposta e il login funziona.

Problema più generale con i cookie

Come puoi vedere, il problema è più generale e non limitato alla sessione ASP.NET. Se stai ospitando OWIN tramite Microsoft.Owin.Host.SystemWeb e tu / qualcosa stai usando direttamente la raccolta System.Web.HttpResponse.Cookies sei a rischio.

Ad esempio, funziona e entrambi i cookie vengono inviati correttamente al browser ...

public ActionResult Index()
{
    HttpContext.GetOwinContext()
        .Response.Cookies.Append("OwinCookie", "SomeValue");
    HttpContext.Response.Cookies["ASPCookie"].Value = "SomeValue";

    return View();
}

Ma non è così e OwinCookie è "perso" ...

public ActionResult Index()
{
    HttpContext.GetOwinContext()
        .Response.Cookies.Append("OwinCookie", "SomeValue");
    HttpContext.Response.Cookies["ASPCookie"].Value = "SomeValue";
    HttpContext.Response.Cookies.Remove("ASPCookie");

    return View();
}

Entrambi testati da VS2013, IISExpress e modello di progetto MVC predefinito.

A partire dalla grande analisi di @TomasDolezal, ho dato un'occhiata sia alla fonte Owin che alla fonte System.Web.

Il problema è che System.Web ha una propria fonte principale di informazioni sui cookie e che non è l'intestazione Set-Cookie. Owin conosce solo l'intestazione Set-Cookie. Una soluzione alternativa è assicurarsi che anche tutti i cookie impostati da Owin siano impostati nella HttpContext.Current.Response.Cookiesraccolta.

Ho creato un piccolo middleware ( sorgente , nuget ) che fa esattamente questo, che deve essere posizionato immediatamente sopra la registrazione del middleware dei cookie.

app.UseKentorOwinCookieSaver();

app.UseCookieAuthentication(new CookieAuthenticationOptions());

In breve, il gestore dei cookie .NET conquisterà il gestore dei cookie OWIN e sovrascriverà i cookie impostati sul livello OWIN . La correzione consiste nell'utilizzare la classe SystemWebCookieManager, fornita come soluzione nel Progetto Katana qui . È necessario utilizzare questa classe o una simile, che costringerà OWIN a utilizzare il gestore dei cookie .NET, quindi non ci sono incoerenze :

public class SystemWebCookieManager : ICookieManager
{
    public string GetRequestCookie(IOwinContext context, string key)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }

        var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
        var cookie = webContext.Request.Cookies[key];
        return cookie == null ? null : cookie.Value;
    }

    public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }
        if (options == null)
        {
            throw new ArgumentNullException("options");
        }

        var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);

        bool domainHasValue = !string.IsNullOrEmpty(options.Domain);
        bool pathHasValue = !string.IsNullOrEmpty(options.Path);
        bool expiresHasValue = options.Expires.HasValue;

        var cookie = new HttpCookie(key, value);
        if (domainHasValue)
        {
            cookie.Domain = options.Domain;
        }
        if (pathHasValue)
        {
            cookie.Path = options.Path;
        }
        if (expiresHasValue)
        {
            cookie.Expires = options.Expires.Value;
        }
        if (options.Secure)
        {
            cookie.Secure = true;
        }
        if (options.HttpOnly)
        {
            cookie.HttpOnly = true;
        }

        webContext.Response.AppendCookie(cookie);
    }

    public void DeleteCookie(IOwinContext context, string key, CookieOptions options)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }
        if (options == null)
        {
            throw new ArgumentNullException("options");
        }

        AppendResponseCookie(
            context,
            key,
            string.Empty,
            new CookieOptions
            {
                Path = options.Path,
                Domain = options.Domain,
                Expires = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc),
            });
    }
}

All'avvio dell'applicazione, assegnalo quando crei le dipendenze OWIN:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    ...
    CookieManager = new SystemWebCookieManager()
    ...
});

Una risposta simile è stata fornita qui, ma non include tutto il codice necessario per risolvere il problema, quindi vedo la necessità di aggiungerlo qui perché il collegamento esterno al Progetto Katana potrebbe non funzionare e questo dovrebbe essere completamente riportato come soluzione anche qui.

Il team di Katana ha risposto al problema sollevato da Tomas Dolezar e ha pubblicato la documentazione relativa alle soluzioni alternative :

Le soluzioni alternative rientrano in due categorie. Uno è quello di riconfigurare System.Web in modo da evitare l'utilizzo della raccolta Response.Cookies e la sovrascrittura dei cookie OWIN. L'altro approccio consiste nel riconfigurare i componenti OWIN interessati in modo che scrivano i cookie direttamente nella raccolta Response.Cookies di System.Web.

• Assicurarsi che la sessione sia stabilita prima dell'autenticazione: il conflitto tra i cookie System.Web e Katana è per richiesta, quindi potrebbe essere possibile che l'applicazione stabilisca la sessione su una richiesta prima del flusso di autenticazione. Questo dovrebbe essere facile da fare quando arriva l'utente per la prima volta, ma potrebbe essere più difficile garantire in seguito quando i cookie di sessione o di autenticazione scadono e / o devono essere aggiornati.
• Disabilita il SessionStateModule: se l'applicazione non si basa sulle informazioni sulla sessione, ma il modulo di sessione sta ancora impostando un cookie che causa il conflitto di cui sopra, è possibile disabilitare il modulo di stato della sessione.
• Riconfigurare CookieAuthenticationMiddleware per scrivere direttamente nella raccolta di cookie di System.Web.

app.UseCookieAuthentication(new CookieAuthenticationOptions
                                {
                                    // ...
                                    CookieManager = new SystemWebCookieManager()
                                });

Vedi l'implementazione di SystemWebCookieManager dalla documentazione (link sopra)

Maggiori informazioni qui

modificare

Di seguito i passaggi che abbiamo preso per risolvere il problema. Sia 1. che 2. hanno risolto il problema anche separatamente, ma abbiamo deciso di applicare entrambi nel caso in cui:

1. Usa SystemWebCookieManager

2. Impostare la variabile di sessione:

protected override void Initialize(RequestContext requestContext)
{
    base.Initialize(requestContext);

    // See http://stackoverflow.com/questions/20737578/asp-net-sessionid-owin-cookies-do-not-send-to-browser/
    requestContext.HttpContext.Session["FixEternalRedirectLoop"] = 1;
}

(nota a margine: il metodo Initialize sopra è il posto logico per la correzione perché base.Initialize rende disponibile Session. Tuttavia, la correzione potrebbe essere applicata anche in seguito perché in OpenId c'è prima una richiesta anonima, quindi reindirizza al provider OpenId e poi indietro all'app. I problemi si verificherebbero dopo il reindirizzamento all'app, mentre la correzione imposta la variabile di sessione già durante la prima richiesta anonima, risolvendo così il problema anche prima che si verifichi un eventuale reindirizzamento)

Modifica 2

Copia e incolla dal progetto Katana 14/05/2016:

Aggiungi questo:

app.UseCookieAuthentication(new CookieAuthenticationOptions
                                {
                                    // ...
                                    CookieManager = new SystemWebCookieManager()
                                });

...e questo:

public class SystemWebCookieManager : ICookieManager
{
    public string GetRequestCookie(IOwinContext context, string key)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }

        var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
        var cookie = webContext.Request.Cookies[key];
        return cookie == null ? null : cookie.Value;
    }

    public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }
        if (options == null)
        {
            throw new ArgumentNullException("options");
        }

        var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);

        bool domainHasValue = !string.IsNullOrEmpty(options.Domain);
        bool pathHasValue = !string.IsNullOrEmpty(options.Path);
        bool expiresHasValue = options.Expires.HasValue;

        var cookie = new HttpCookie(key, value);
        if (domainHasValue)
        {
            cookie.Domain = options.Domain;
        }
        if (pathHasValue)
        {
            cookie.Path = options.Path;
        }
        if (expiresHasValue)
        {
            cookie.Expires = options.Expires.Value;
        }
        if (options.Secure)
        {
            cookie.Secure = true;
        }
        if (options.HttpOnly)
        {
            cookie.HttpOnly = true;
        }

        webContext.Response.AppendCookie(cookie);
    }

    public void DeleteCookie(IOwinContext context, string key, CookieOptions options)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }
        if (options == null)
        {
            throw new ArgumentNullException("options");
        }

        AppendResponseCookie(
            context,
            key,
            string.Empty,
            new CookieOptions
            {
                Path = options.Path,
                Domain = options.Domain,
                Expires = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc),
            });
    }
}

Le risposte sono già state fornite, ma in owin 3.1.0 esiste una classe SystemWebChunkingCookieManager che può essere utilizzata.

https://github.com/aspnet/AspNetKatana/blob/dev/src/Microsoft.Owin.Host.SystemWeb/SystemWebChunkingCookieManager.cs

https://raw.githubusercontent.com/aspnet/AspNetKatana/c33569969e79afd9fb4ec2d6bdff877e376821b2/src/Microsoft.Owin.Host.SystemWeb/SystemWebChunkingCookieManager.cs

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    ...
    CookieManager = new SystemWebChunkingCookieManager()
    ...
});

Se stai impostando i cookie nel middleware OWIN da solo, allora l'utilizzo OnSendingHeaderssembra aggirare il problema.

Ad esempio, owinResponseCookie2verrà impostato l'utilizzo del codice seguente , anche se owinResponseCookie1non lo è:

private void SetCookies()
{
    var owinContext = HttpContext.GetOwinContext();
    var owinResponse = owinContext.Response;

    owinResponse.Cookies.Append("owinResponseCookie1", "value1");

    owinResponse.OnSendingHeaders(state =>
    {
        owinResponse.Cookies.Append("owinResponseCookie2", "value2");
    },
    null);

    var httpResponse = HttpContext.Response;
    httpResponse.Cookies.Remove("httpResponseCookie1");
}

Ho affrontato il problema simile con Visual Studio 2017 e .net MVC 5.2.4 , aggiornando Nuget Microsoft.Owin.Security.Google alla versione più recente che attualmente è 4.0.1 ha funzionato per me! Spero che questo aiuti qualcuno!

La soluzione di codice a una riga più veloce:

HttpContext.Current.Session["RunSession"] = "1";

Aggiungi questa riga prima del metodo CreateIdentity:

HttpContext.Current.Session["RunSession"] = "1";
var userIdentity = userManager.CreateIdentity(user, DefaultAuthenticationTypes.ApplicationCookie);
_authenticationManager.SignIn(new AuthenticationProperties { IsPersistent = rememberLogin }, userIdentity);

Ho avuto lo stesso sintomo dell'intestazione Set-Cookie non inviata, ma nessuna di queste risposte mi ha aiutato. Tutto ha funzionato sul mio computer locale ma, quando distribuito alla produzione, le intestazioni del set-cookie non sarebbero mai state impostate.

Si è scoperto che era una combinazione di utilizzo di un custom CookieAuthenticationMiddlewarecon WebApi insieme al supporto di compressione WebApi

Fortunatamente stavo usando ELMAH nel mio progetto che mi ha permesso di registrare questa eccezione:

System.Web.HttpException Server non può aggiungere l'intestazione dopo che le intestazioni HTTP sono state inviate.

Il che mi ha portato a questo problema GitHub

Fondamentalmente, se hai una configurazione strana come la mia, vorrai disabilitare la compressione per i tuoi controller / metodi WebApi che impostano i cookie o provare il OwinServerCompressionHandler.