ASP.NET les Cookies SessionId + OWIN ne sont pas envoyés au navigateur

en commençant par la grande analyse de @TomasDolezal, j'ai regardé à la fois L'Owin et le système.Web source.

le problème est ce système.Le Web a sa propre source principale d'informations sur les cookies et ce n'est pas L'en-tête Set-Cookie. Owin ne connaît que L'en-tête des cookies. Une solution consiste à s'assurer que tous les cookies définis par Owin sont également définis dans la collection HttpContext.Current.Response.Cookies .

j'ai fait un petit middleware ( source , nuget ) qui fait exactement cela, qui est destiné à être placé immédiatement au-dessus de l'enregistrement middleware cookie middleware.

app.UseKentorOwinCookieSaver();

app.UseCookieAuthentication(new CookieAuthenticationOptions());

en bref, le gestionnaire de cookies .NET va gagner sur le gestionnaire de cookies OWIN et écraser les cookies définis sur la couche OWIN . Le correctif est d'utiliser la classe SystemWebCookieManager, fournie comme solution sur le projet Katana ici . Vous devez utiliser cette classe ou une similaire, qui va forcer OWIN à utiliser le gestionnaire de cookies .NET afin qu'il n'y ait pas d'incohérences :

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

dans votre démarrage de l'application, il suffit de l'assigner lorsque vous créez vos dépendances OWIN:

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

une réponse similaire a été fournie ici, mais elle n'inclut pas toute la base de code nécessaire pour résoudre le problème, donc je vois un besoin de l'ajouter ici parce que le lien externe au projet Katana peut descendre et cela devrait être entièrement chroniqué comme une solution ici aussi.

Katana équipe a répondu à la problème Tomas Dolezar soulevées, et publié de la documentation sur les solutions de contournement :

Solutions de contournement se répartissent en deux catégories. L'une consiste à reconfigurer Système.Web donc il évite d'utiliser la réponse.Collection de Cookies et l'écrasement de la OWIN cookies. L'autre approche consiste à reconfigurer les composants touchés OWIN afin qu'ils écrivent des cookies directement à Système.Web Réponse.La collecte des Cookies.

• S'assurer que la session est établie avant l'authentification: le conflit entre les systèmes.Cookies Web et Katana est par demande, il peut donc être possibilité pour la demande d'établir la session sur demande avant le processus d'authentification. Cela devrait être facile à faire lorsque le l'utilisateur arrive d'abord, mais il peut être plus difficile de garantir plus tard, lorsque le les cookies de session ou d'autorisation expirent et / ou doivent être rafraîchis.
• désactiver le module SessionStateModule-si l'application ne se base pas sur les informations de session, mais que le module de session est encore en train de définir un cookie qui provoque le conflit ci-dessus, alors vous pouvez envisager de désactiver le module d'état de session.
• Reconfigure le CookieAuthenticationMiddleware pour écrire directement au système.La collection de cookies de Web.

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

Voir SystemWebCookieManager mise en œuvre de la documentation (lien ci-dessus)

plus d'information ici

Modifier

ci-dessous les mesures que nous avons prises pour résoudre le problème. Les deux 1. et 2. nous avons également résolu le problème séparément, mais nous avons décidé d'appliquer les deux juste au cas où:

1. Use SystemWebCookieManager 151990920"

2. Définir la variable de session:

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

    // See /q/asp-net-sessionid-owin-cookies-do-not-send-to-browser-68173/"FixEternalRedirectLoop"] = 1;
}

(note latérale: la méthode D'initialisation ci-dessus est l'endroit logique pour le repère parce que la base.Initialize rend la Session disponible. Cependant, le correctif pourrait aussi être appliqué plus tard car dans OpenId il y a d'abord une requête anonyme, puis une redirection vers le fournisseur OpenId et ensuite de nouveau vers l'application. Les problèmes se produiraient après la redirection vers l'application alors que le correctif définit la variable session déjà lors de la première requête anonyme réparant ainsi le problème avant toute redirection de retour arrive même)

Edit 2

Copier-coller à partir de la Katana projet 2016-05-14:

ajouter ce qui suit:

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

...et ceci:

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

les réponses ont déjà été fournies, mais dans owin 3.1.0, il y a une classe SystemWebChunkingCookieManager qui peut être utilisée.

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()
    ...
});

si vous installez vous-même des cookies dans OWIN middleware, l'utilisation de OnSendingHeaders semble contourner le problème.

par exemple, en utilisant le code ci-dessous owinResponseCookie2 sera défini, même si owinResponseCookie1 n'est pas:

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

Le plus rapide de la ligne de solution de code:

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

il suffit d'ajouter cette ligne avant la méthode CreateIdentity:

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

j'ai eu le même symptôme de L'absence d'envoi de L'en-tête de L'ensemble-Cookie, mais aucune de ces réponses ne m'a aidé. Tout fonctionnait sur ma machine locale, mais lorsqu'elle était déployée à la production, les en-têtes de Set-cookie ne se réglaient jamais.

il s'avère que c'était une combinaison de l'utilisation d'une coutume CookieAuthenticationMiddleware avec WebApi avec support de compression WebApi

heureusement que J'utilisais ELMAH dans mon projet qui m'a permis à cette exception en cours de la session:

Système

.Web.Le serveur HttpException ne peut pas ajouter d'en-tête après HTTP les en-têtes ont été envoyés.

qui m'a conduit à ce Github Issue

essentiellement, si vous avez une configuration étrange comme la mienne, vous voudrez désactiver la compression pour vos contrôleurs WebApi / méthodes qui fixent les cookies, ou essayer le OwinServerCompressionHandler .