Wie funktionieren zustandslose Server?

Question

Ich versuche das zu verstehen. Normalerweise wird bei jedem Benutzer-Login-System die Serverseite eine Sitzung erstellen, während die Benutzer-Clientseite ein Cookie ist. Wenn Leute über zustandslose Server-Seite, stateful client Seite sprechen, was meinen sie? Serverseite keine Notwendigkeit Sitzung verwenden Benutzer verfolgen? Verwenden Sie nur Cookies auf der Client-Seite, um den Benutzer zu überprüfen? meine ich, wenn ich den Server ändere, merkt der Benutzer das nicht und kann den Dienst weiterhin benutzen?

Wie konfiguriert man Feder-Sicherheit, um dies zu tun?

Answer 1

Verfolgen eines Benutzers über Server ist schwierig für echte zustandslose Server-Seite. Die meiste Zeit sind die Dinge ein staatenloser Server, bei dem Logins die Ausnahme sind. Die große Sache mit zustandslosen Servern ist jedoch, dass das Clustering sehr einfach ist, sodass Sie horizontal skalieren können.

In Java können Sie es statuslos machen, indem Sie entweder Cookies verwenden, um Anmeldeinformationen zu speichern, oder verteilte Hashes verwenden. Im Allgemeinen akzeptieren Menschen die Verwendung von Memcache und sagen, dass sie statuslos sind, da der Status außerhalb des Webservers gespeichert wird. Dadurch kann der Benutzer jeden Webserver in der Farm verwenden und trotzdem sicher authentifiziert werden. In Java haben wir viele verteilte Hash-Implementierungen, die Sie mit Spring verwenden können, so dass Sie Memcache dafür nicht verwenden müssen.

Die andere Option besteht darin, Cookies zu verwenden, um ein kryptographisch sicheres Hash-Ticket namens HMAC zu speichern. Die Verwendung von Cookies verhindert die Verwendung der Sitzung, so dass der Webserver staatenlos ist. Mit HMAC können Sie einen Datenblock signieren, der nicht von Dritten gefälscht oder erstellt werden kann und garantiert von Ihnen stammt. Dies erfordert keine externen Serverressourcen (den Cache), um den Benutzer zu authentifizieren, damit er besser skaliert werden kann. Es gibt jedoch einige Sicherheitsbedenken, die Sie beachten müssen. FYI Google verwendet diese Technik, um horizontal zu skalieren. Ein HMAC ist nicht wie SHA1 oder andere Cyrpto-Hashes. Sie benötigen einen geheimen Schlüssel, der auf jedem Server in der Farm sein muss. Das muss auch mit einem symmetrischen Verschlüsselungsschlüssel geschützt werden, um sicherzustellen, dass er sicher auf dem Server gespeichert wird, sollte jemand die Datei erhalten. Auch HMACs Informationen werden im Klartext gespeichert, so dass Sie zwar den Benutzernamen oder die E-Mail in den Cookie einfügen können, aber der eigentliche Krypto Hash ist für jeden verfügbar. Wenn jemand diesen Keks erhalten würde, könnte er sich als dieser Benutzer ausgeben. Aus diesem Grund sind HMACs in der Regel nur für eine bestimmte Zeit gültig. Danach verfallen sie, so dass jemand, der sie erhält, nicht für immer auf dieses Konto zugreifen kann.

Also HMACs haben diese Schwäche und Sie sollten vorsichtig sein, in welchen Anwendungen Sie sie verwenden. Es wäre eine wirklich schlechte Idee für Paypal, dieses Schema zu verwenden, weil alles, was ich tun muss, ist Ihre sichere Cookie dann übertragen Sie alle Ihre Geld für mich. Der große Vorteil ist, dass Ihre App wirklich staatenlos ist.

Die letzte Option besteht darin, Ihre Java-Sitzungen in einem verteilten Hash zu speichern. PHP und andere Plattformen werden ihre Sitzungen in der Datenbank ablegen, den verarmten Cache verarmen oder in Memcache ablegen. Mit Java können Sie das Gleiche tun. Sie können Ihre Sitzungsobjekte auch in den verteilten Cache stellen. Diese Option ist in Ungnade gefallen, weil die Leute denken: "Cool, jetzt kann ich alles, was ich will, in meine Sitzung stecken und es wird staatenlos sein." Wie bei allen verteilten Caches sind jedoch die Übertragungsgeschwindigkeit, die Replikationszeit und die Nutzlastgröße begrenzt. Dies gilt für Java oder Memcache. Halten Sie Ihre Sitzungen klein, und das funktioniert gut. Wirf alles in die Sitzung und schon geht es wieder um Skalierungsprobleme mit einem einzelnen Server. Und tatsächlich ist es wahrscheinlich schlimmer, als wenn Sie Ihren Server gerade statusfähig gemacht hätten, weil Grid-Computing manchmal schlechter ist als ein einzelner Server.

Update: Hier finden Sie eine Liste von Java verteilt Caching Bibliotheken, die Sie dies tun können:

http://www.manageability.org/blog/stuff/distributed-cache-java

Answer 2

A staatenlos Dienst ein Dienst ist, der keine Daten auf dem Anwendungsserver speichert. Es liest oder schreibt Daten in die Datenbank, gibt einen Wert zurück (oder nicht), und danach werden alle Informationen zur Aufgabe selbst vergessen.

Ein stateful Service wird verwendet, um Transaktionen durchzuführen, das ist eine Reihe von Aufgaben, die von dem Ergebnis vorhergehender Aufgaben abhängen. Das einfachste Beispiel ist das Senden einer Bestellung in einem Webshop, wo Sie Ihre Produkte in einem Einkaufswagen sammeln, und wenn Sie auschecken, geben Sie Ihre Kontodaten auf einer Seite, speichern Sie es, geben Sie Ihre Rechnungsadresse ein, speichern Sie sie dann Bestätigen Sie Ihre Bestellung und schließen Sie die Transaktion ab. Jeder Schritt hängt vom erfolgreichen Ergebnis des vorherigen Schritts ab, und die Daten müssen bis zum Abschluss des letzten dieser Schritte oder der Stornierung der Transaktion aufbewahrt werden. In diesem Fall muss ein Rollback durchgeführt werden, um den Kontostand wiederherzustellen Es war bevor du ausgecheckt hast.

In den meisten Fällen können Sie Transaktionen auf beide Arten implementieren, aber wenn Sie statusfreie Dienste verwenden, müsste Ihre Clientanwendung sich um die ordnungsgemäße Reihenfolge und Ausführung von Aufgaben kümmern, oder Sie müssten andere finden Möglichkeit, die Transaktionsinformationen korrekt zu speichern und die Rollbacks zu verwalten. Das wäre eine Stateful Client-Seite, wie Sie es nannten.

All dies ist jedoch ziemlich allgemein, und Sicherheit und/oder Sitzungsbehandlung müssten in jedem dieser Fälle berücksichtigt werden. Sie können Sitzungsinformationen sehr gut zur Authentifizierung statusfreier Serviceanrufe verwenden. Sie müssen jeden Anruf nur einzeln authentifizieren, indem Sie beispielsweise eine Sitzungs-ID oder eine Benutzer-ID oder ein anderes Sicherheitstoken an die Geschäftsdaten anhängen.