ASP.NET_SessionId + OWIN Cookies nicht senden an browser
Ich habe ein seltsames problem mit Owin cookie-Authentifizierung.
Wenn ich beginne meinen IIS-server-Authentifizierung funktioniert einwandfrei auf IE/Firefox und Chrome.
Ich begann dabei einige Tests mit Authentifizierung und Anmeldung auf verschiedenen Plattformen und ich habe mit einem seltsamen Fehler. Sporadisch der Owin-framework /IIS einfach nicht senden Sie keine cookies in den Browsern. Ich geben Sie einen Benutzernamen und ein Passwort korrekt ist, wird der code ausgeführt, aber kein cookie geliefert bekommt an den browser überhaupt. Wenn ich den server neu starten, beginnt es zu arbeiten, dann irgendwann werde ich versuchen, den login und wieder cookies unterbinden geliefert. Stepping über den code, der nichts tut und wirft keine Fehler aus.
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);
}
}
}
});
Und innerhalb meiner Anmeldung habe ich den folgenden code:
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);
Update 1: Es scheint, dass eine Ursache für das problem ist, wenn ich die Elemente hinzufügen, um Sitzung die Probleme beginnen. Hinzufügen von etwas einfaches wie Session.Content["ABC"]= 123
scheint zu erstellen das problem.
Was ich machen kann ist wie folgt:
1) (Chrome), Wenn ich mich anmelden bekomme ich ASP.NET_SessionId + meine Authentifizierungs-cookie.
2) ich gehe auf eine Seite setzt, die eine Sitzung.Inhalt...
3) Öffnen Sie ein neues browser (Firefox) und versuchen Sie den login und es keine ASP.NET_SessionId noch tut es erhalten Sie eine Authentifizierungs-Cookie
4), Während der erste browser der ASP.NET_SessionId es weiter zu arbeiten. Die minute, die ich zu entfernen dieses cookie, es hat das gleiche problem wie alle anderen Browser
Ich arbeite auf ip-Adresse (10.x.x.x) und localhost.
Update 2: Force Erstellung von ASPNET_SessionId
zuerst auf mein login_load Seite vor der Authentifizierung mit OWIN.
1.) bevor ich die Authentifizierung mit OWIN ich eine zufällige Session.Content
Wert auf meiner login-Seite zum starten der ASP.NET_SessionId
2) dann habe ich zu authentifizieren und weitere Sitzungen
3) Andere Browser scheinen jetzt arbeiten
Dies ist Bizarr. Ich kann nur zu dem Schluss kommen, dass dies etwas zu tun mit ASP und OWIN, die denken, Sie sind in verschiedenen Domänen oder sowas.
Update 3 - Seltsames Verhalten zwischen den beiden.
Zusätzliche seltsames Verhalten identifiziert - Timeout von Owin und ASP-session ist anders. Was ich sehe ist, dass meine Owin-Sitzungen sind am Leben zu bleiben, länger als meine ASP-Sitzungen durch einen bestimmten Mechanismus. Also beim einloggen:
1.) Ich habe eine cookied basierte auth session
2.) Ich ein paar session-Variablen
Meine session-Variablen(2) "sterben", bevor der owin-cookie, session-variable Kräfte, re-login, die Ursachen unerwarteten Verhaltens während meiner gesamten Anwendung. (Person angemeldet ist, aber nicht wirklich angemeldet)
Update 3B
Nachdem einige Graben, sah ich einige Kommentare auf einer Seite, die sagen, dass die "Formen" Zeitlimit für Authentifizierung und session-timeout anpassen müssen. Ich denke normalerweise die beiden synchron sind, aber aus irgendeinem Grund sind die beiden nicht synchron.
Zusammenfassung von Workarounds
1) erstellen einer ersten Sitzung vor der Authentifizierung. Im Grunde erstellen Sie die Sitzung, wenn Sie die Anwendung starten Session["Workaround"] = 0;
2) [Experimental], wenn Sie weiterhin cookies stellen sicher, dass Ihre OWIN timeout /Länge länger ist als die sessionTimeout in Ihrer Website.config (in der Prüfung)
Danke!...Hinzufügen Session in ExternalLogin fest für mich...das ist voodoo-Zauber...ich habe bereits verschwendet 6 Uhr an Jagd auf dieses Problem hin..
InformationsquelleAutor Piotr Stulinski | 2013-12-23
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich hatte das gleiche problem und verfolgt die Ursache zu OWIN ASP.NET hosting Umsetzung. Ich würde sagen, es ist ein bug.
Einige hintergrund
Meine Erkenntnisse stützen sich auf diese assembly-Versionen:
OWIN nutzt es die eigene Abstraktion zur Arbeit mit der response-Cookies (Microsoft.Owin.ResponseCookieCollection). Diese Umsetzung direkt umschließt Antwort-Header-Sammlung und entsprechend updates Set-Cookie header. OWIN ASP.NET host (Microsoft.Owin.Host.SystemWeb) nur Packungen System.Web.HttpResponse und es ist Headern Sammlung. Also, wenn neues cookie erstellt durch OWIN, Antwort Set-Cookie header wird direkt verändert.
Aber ASP.NET auch nutzt es die eigene Abstraktion zur Arbeit mit der response-Cookies. Dies stellte uns als System.Web.HttpResponse.Cookies Eigentum und umgesetzt von versiegelten Klasse System.Web.HttpCookieCollection. Diese Umsetzung nicht umbrochen Antwort Set-Cookie header direkt, sondern verwendet einige Optimierungen und eine Handvoll interne Benachrichtigungen zu manifestieren, es ist der veränderten Zustand response-Objekt.
Dann gibt es einen Punkt, spät in der Anfrage Lebenszeit, wo HttpCookieCollection Zustand getestet (System.Web.HttpResponse.GenerateResponseHeadersForCookies()) und cookies sind serialisiert Set-Cookie header. Wenn diese Sammlung ist in einigen bestimmten Zustand, ganzes Set-Cookie-header wird zuerst gelöscht und neu erstellt aus gespeicherten cookies in der Sammlung.
ASP.NET Sitzung-Implementierung verwendet System.Web.HttpResponse.Cookies Eigenschaft zu speichern, es ist ASP.NET_SessionId cookie. Auch gibt es einige grundlegende Optimierungen in ASP.NET session-state-Modul (System.Web.SessionState.SessionStateModule) umgesetzt durch statische Eigenschaft namens s_sessionEverSet das ist ziemlich selbsterklärend. Wenn Sie jemals etwas lagern, um den Sitzungsstatus in Ihrer Anwendung, in diesem Modul wird ein wenig mehr Arbeit, für jede Anforderung.
Zurück zu unserem login-problem
Alle diese Stücke Ihre Szenarien erklärt werden kann.
Fall 1 - Session war nie
System.Web.SessionState.SessionStateModule, s_sessionEverSet Eigenschaft ist false. Keine session-id ' s generiert werden, die durch session-state-Modul und System.Web.HttpResponse.Cookies Sammlung Zustand ist nicht erkannt, als geändert. In diesem Fall OWIN cookies gesendet werden, korrekt an den browser und das login funktioniert.
Fall 2 - Sitzung verwendet wurde, irgendwo in der Anwendung, aber nicht, bevor der Benutzer versucht, sich zu authentifizieren
System.Web.SessionState.SessionStateModule, s_sessionEverSet-Eigenschaft true ist. Session-Id ' s generiert werden SessionStateModule, ASP.NET_SessionId Hinzugefügt System.Web.HttpResponse.Cookies Sammlung, aber es ist später entfernt Wunsch Lebensdauer als Benutzer-session ist in der Tat leer. In diesem Fall System.Web.HttpResponse.Cookies Sammlung Zustand ist erkannt, als geändert und Set-Cookie header wird zuerst gelöscht, bevor ein Cookie serialisiert header-Wert.
In diesem Fall OWIN Reaktion cookies sind "verloren" und der Benutzer ist nicht authentifiziert, und gelangt zurück auf die login-Seite.
Fall 3 - Sitzung verwendet wird, bevor der Benutzer versucht, sich zu authentifizieren,
System.Web.SessionState.SessionStateModule, s_sessionEverSet-Eigenschaft true ist. Session-Id ' s generiert werden SessionStateModule, ASP.NET_SessionId Hinzugefügt System.Web.HttpResponse.Cookies. Aufgrund der internen Optimierung in System.Web.HttpCookieCollection und System.Web.HttpResponse.GenerateResponseHeadersForCookies() Set-Cookie-header wird erstmal NICHT gelöscht, sondern nur aktualisiert.
In diesem Fall sind beide OWIN-Authentifizierung cookies und ASP.NET_SessionId cookie gesendet werden, in Reaktion und login funktioniert.
Allgemeines problem mit cookies
Wie Sie sehen können, das problem ist eher allgemein und nicht beschränkt auf ASP.NET Sitzung. Wenn Sie hosting-OWIN durch Microsoft.Owin.Host.SystemWeb und Sie/etwas ist direkt mit System.Web.HttpResponse.Cookies Sammlung sind Sie in Gefahr.
Beispielsweise dies funktioniert und beide cookies werden korrekt gesendet, um browser...
Aber dies nicht und OwinCookie ist "verloren"...
Beide getestet von VS2013, IISExpress und Standard-MVC-Projekt-Vorlage.
Dies ist ein ziemlich ernster Fehler, vor allem, da Sie verpackt owin die Vorlage für vs2013.
Für jeden, der will dies weiter verfolgen, habe ich ein test-Projekt an github.com/Neilski/IdentityBugDemo
Laufen in dieses problem, da der Controller.TempData verwendet Session als Zusatzspeicher. Können leicht reproduzieren die Unfähigkeit, wenn eine ASP_NET.SessionId-cookie nicht vorhanden ist, aus einer vorherigen Anfrage.
Endlich! Was für eine seltsame Frage dieser ist. Danke. Dieses Thema ist immer noch mehr als zwei Jahre nach dieser Antwort geschrieben wurde.
InformationsquelleAutor Tomas Dolezal
Beginnend mit der großen Analyse von @TomasDolezal, ich hatte einen Blick auf sowohl die Owin und das System.Web-Quelle.
Das problem ist das System.Web hat seine eigenen master-Quelle von cookie-Informationen und das ist nicht der Set-Cookie-header. Owin kennt nur die Set-Cookie-header. Ein workaround ist, um sicherzustellen, dass alle cookies, die von Owin sind auch in der
HttpContext.Current.Response.Cookies
Sammlung.Habe ich eine kleine middleware ( Quelle , nuget), die macht genau das, was gebracht werden soll, unmittelbar oberhalb der cookie-middleware Registrierung.
Sie haben, um es zu aktivieren mit
app.UseKentorCookieMiddlewareSaver();
im Autostart.Auth.cs. Es sollte in der Lage logout-cookie Lichtung zu.Danke, dass Sie so viel Anders Abel, beide login-und logout funktioniert jetzt. Aber der code im obigen Kommentar geändert werden muss (weil ich es folgte,:) ohne Erfolg):
app.UseKentorOwinCookieSaver()
und vielleicht enthalten Sie original-Antwort, wie in das Paket GitHub-Seite.Vielen Dank für bemerken die falsche doc. Es ist eigentlich schon fest auf der GitHub-Seite, aber ich habe aktualisiert in meiner Antwort hier, als auch jetzt.
Ich bin versucht, hinzuzufügen Meetup Anmeldungen für dieses github-Projekt: github.com/owin-middleware/OwinOAuthProviders". Ich fügte hinzu, Asana nur den anderen Tag und hatte keine Probleme, aber für einige Grund, bei Meetup, das erwarten die AuthenticationManager.GetExternalLoginInfoAsync () - Methode in der Konto//ExternalLoginCallback ist die Rückgabe null. Leider, Ihr NuGet-Paket nicht lösen, mein Problem. Ich Frage mich, wenn Sie hatte einige Zeit, um überprüfen Sie mit mir, wie Sie vielleicht in der Lage sein, um besser das Problem zu beheben und drücken Sie, um Ihr Projekt.
InformationsquelleAutor Anders Abel
Kurz, .NET-cookie-manager gewinnen, der OWIN-cookie-manager und überschreiben cookies auf der OWIN-Schicht. Der fix ist die Verwendung der SystemWebCookieManager Klasse, die als eine Lösung auf dem Katana-Projekt hier. Sie müssen diese Klasse verwenden, oder eine ähnliche, die Kraft OWIN, die zu benutzen .NET-cookie-manager, so gibt es keine Unstimmigkeiten:
In Ihre Anwendung starten, weisen Sie einfach es, wenn Sie Ihre OWIN Abhängigkeiten:
Eine ähnliche Antwort wurde hier angeboten, aber es enthält nicht alle der code-Basis erforderlich, um das problem zu lösen, so sehe ich es hinzufügen müssen, weil hier der externe link zu dem Katana-Projekt kann nach unten gehen und dies vollständig aufzählen, wie hier eine Lösung als gut.
Ist gilt ASP.NET Webforms 4.6.1 ? Meine webApp verwendet
ASP.NET Webforms, OWIN, ADFS
Gibt es in Ihrem web-app verwenden OWIN cookies? Dann ja.
Im code
Startup.ConfigureAuth
wir habenapp.UseCookieAuthentication
undapp.UseWsFederationAuthentication
und schließlichapp.UseStageMarker
scheint, wie ich fand die Lösung für dieses beschissene bug 🙂
InformationsquelleAutor Alexandru
Katana team beantwortet Problem Tomas Dolezar erhoben und veröffentlicht Dokumentation über workarounds:
Sehen SystemWebCookieManager Umsetzung aus der Dokumentation (link oben)
Mehr Informationen hier
Bearbeiten
Unten die Schritte, die wir ergriffen haben, um das Problem zu lösen. Sowohl 1. und 2. das problem, auch getrennt, aber wir beschlossen, gelten beide nur für den Fall:
1.
Verwenden SystemWebCookieManager
2.
Das session-variable:
(Anmerkung: die Initialize-Methode oben ist der logische Ort für das Update, weil base.Initialisieren macht-Sitzung zur Verfügung. Allerdings wird das Update könnte auch nachträglich angewendet werden, da in OpenId gibt es zunächst eine anonyme Anfrage, dann Weiterleitung zum OpenId-provider und dann wieder zurück in die app. Die Probleme, die auftreten würde, nach der Umleitung wieder auf die app, während der Korrektur wird die session-variable schon während der ersten anonymen Anfrage somit das problem beheben, bevor Sie jede Umleitung wieder auch passiert)
Edit 2
Copy-paste aus der Katana Projekt 2016-05-14:
Hinzufügen:
...und so:
Enthalten die Schritte, die wir ergriffen haben, um das Problem zu lösen. Hast du erfahren, ob dein Problem bezogen war?
Ich bin mit der Web-Api-2 + Owin-middleware + redis-cache für session-management für die Authentifizierung. Ich habe versucht, SystemWebCookieManager und es didn ' T lösen das Problem, das ich hatte, wo die auth cookies nicht gesetzt werden. Mit "UseKentorOwinCookieSaver" gelöst, aber ich bin nicht allzu gern eine zusätzliche Abhängigkeit...
Löschen der session für mich gearbeitet. Keine externen Abhängigkeiten benötigt. Setzen Sie diese
ControllerContext.HttpContext.Session.RemoveAll();
in IhremExternalLogin()
Aktion, vor dem AufrufChallengeResult()
. Ich weiß nicht, ob es die beste Lösung, aber die einfachste.sicher, nehmen Sie einfach beachten Sie die
?.
(null-conditional operator) funktioniert nur in C# 6.InformationsquelleAutor thomius
Wenn Sie das setzen von cookies in OWIN-middleware selbst, dann mit
OnSendingHeaders
scheint sich um das problem.Beispielsweise mit dem folgenden code
owinResponseCookie2
eingestellt werden, obwohlowinResponseCookie1
ist nicht:InformationsquelleAutor Appetere
Antworten erfolgt bereits, aber in owin 3.1.0, es ist ein SystemWebChunkingCookieManager Klasse, die verwendet werden können.
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
Ja, es ist immer noch ein Problem in 3.1.0 für mich und brauchte das cookie-manager, wird als Standard ist immer noch die ChunkingCookieManager.
kann wo eingesetzt werden? und wie?
Hinzugefügt code-Beispiel.
danke. Ich denke, gestern habe ich die Unterscheidung zwischen SystemCCM und CCM also ich werde auf jeden Fall check this out
InformationsquelleAutor jonmeyer
Die Schnellste one-line-code-Lösung:
Fügen Sie einfach diese Zeile vor CreateIdentity Methode:
HttpContext.Current.Session["RunSession"] = "1";
? in Globa.asaxSession_Start
?Es ist in der Tat die einfachste und Schnellste Lösung zur Verfügung, und bis zur Lösung dieses Problems wird nicht in die Strategie (bereits angekündigt) - ich zum Beispiel würde lieber Einzeiler, statt einer Klasse + Reihe von Abhängigkeiten. Diese Lösung wird unterschätzt IMHO.
Ich habe es in meinem AuthManager oben IssueAuthToken Methode
InformationsquelleAutor Alexander Trofimov
Ich hatte das gleiche symptom der Set-Cookie-header nicht gesendet, aber keine dieser Antworten hat mir geholfen. Alles funktionierte auf meiner lokalen Maschine, aber wenn Sie eingesetzt werden, um die Produktion der set-cookie-Kopfzeilen würden nie eingestellt.
Es stellt sich heraus, es war eine Kombination aus der Verwendung einer eigenen
CookieAuthenticationMiddleware
mit WebApi zusammen mit WebApi-KomprimierungZum Glück war ich mit ELMAH in meinem Projekt, das mich zu dieser Ausnahme wird protokolliert:
Das führte mich zu diesem GitHub Issue
Grundsätzlich, wenn Sie eine ungerade setup wie mir Sie wollen die Komprimierung deaktivieren für Ihre WebApi-Controller/- Methoden, die cookies setzen oder versuchen, die
OwinServerCompressionHandler
.InformationsquelleAutor Hugh Jeffner