2016-06-18 11 views
0

Ich habe eine Asp.Net Core RC2-Anwendung und ich habe Probleme mit der Authentifizierung von Cookies. In startup.cs Datei habe ich eine Basiskonfiguration:Cookie-Schlüssel im Speicher gespeichert, kann nicht wechseln Server

app.UseIdentity(); 
app.UseCookieAuthentication(); 

Ich bin nicht EntityFramework verwenden, weil ich eine documental Datenbank bin mit, für die ich Identität Schnittstellen IUserStore und IRoleStore umgesetzt.

Wenn ich mich bei debug in localhost anmelde, auch wenn ich persistente Cookies setze, bleiben sie gültig, bis ich die Anwendung herunterfahre. Wenn ich neu starte, sind die Cookies abgelaufen und der Server leitet mich zur Anmeldeseite um. Das sagt mir, dass die Schlüssel des Kekses im Gedächtnis bleiben. Warum speichert es keine Schlüssel in den Profildatensätzen des Benutzers in db? Cookies funktionieren, bis die Anwendung am Leben erhalten wird.

Dies ist ein Problem, wenn ich die Anwendung auf dem Produktionsserver bereitstellen. Ich verwende eine Produktions-/Staging-Lösung und habe festgestellt, dass alle angemeldeten Benutzersitzungen ablaufen, wenn ich die Anwendung im Staging-Modus austrage und die Server wechseln. Das ist ein großes Problem. Ich kann den Schlüssel auch nicht in einem lokalen Verzeichnis teilen, wie von https://docs.asp.net/en/latest/security/data-protection/compatibility/cookie-sharing.html vorgeschlagen, weil zwei Server unterschiedlich sind. Wie kann ich lösen?

+0

Sind Sie besorgt, dass Menschen würden abgemeldet werden, wenn Sie auf eine neue Maschine migrieren? Warum? –

+0

Denn mit einer agilen Entwicklung könnte ich auch wie jeden Tag die Maschine wechseln – tmm360

+1

Irgendeinen Grund, warum ** Sie nicht ** verteilte Speichercache verwenden können, wie redis? Die Redis-Unterstützung kommt mit ASP.NET Core aus der Box, Sie brauchen nur einen Redis-Cluster und fügen das Paket zu Ihrer Anwendung hinzu und rufen die Startup-Klasse 'AddRedisCache()' auf, bevor Ihre Autorisierungs-Middleware registriert wird? Dadurch speichern Ihre Apps ihre Werte in Redis und nicht im Standard InMemoryCache. – Tseng

Antwort

1

ich glaube, das Problem ist, dass Sie die gleichen Datenschutzschlüssel auf mehreren Rechnern verwenden müssen, während die documentation sagt, dass die Standardeinstellungen sind gut für eine einzelne Maschine

So ist die Lösung die Kontrolle über die nehmen ist, Speicherort, an dem die Schlüssel gespeichert sind, sodass Sie die Schlüssel für jeden Server zusammen mit Ihrer App bereitstellen können. Ich musste dies auch in meiner App tun, da ich den Datenschutz verwende, um einige Dinge in der db zu verschlüsseln, wie zum Beispiel Social Authentic Secrets, und ich muss in der Lage sein, diese zu entschlüsseln, wenn die App auf einen anderen Rechner migriert wird.

Ich habe die Schlüsselstelle in meiner app wie dies in Start ändern:

string pathToCryptoKeys = appBasePath + System.IO.Path.DirectorySeparatorChar + "dp_keys" + System.IO.Path.DirectorySeparatorChar; 
services.AddDataProtection() 
      .PersistKeysToFileSystem(new System.IO.DirectoryInfo(pathToCryptoKeys)); 

aber es ist sehr, sehr wichtig, diese Schlüssel zu halten sicher so viel Vorsicht soll über, wo man im Denken verwendet werden Speichern Sie sie und wer hat Zugriff auf diesen Ort, unter dem Approst wie in meinem Beispiel zu setzen ist wahrscheinlich nicht die beste Lösung