Um das Problem "keine beste Antwort" zu vermeiden, werde ich daher nicht den besten Weg, sondern die übliche oder gebräuchlichste Art der Behandlung von Sitzungen bei der Verwendung des Tornado-Frameworks fragen. Das heißt, wenn wir keine Drittanbieter-Authentifizierung (OAuth, etc.) verwenden, sondern lieber unsere eigene Benutzer-Tabelle mit sicheren Cookies im Browser haben möchten, aber die meisten der Sitzungsinformationen auf dem Server gespeichert sind, was ist das? üblichste Art, dies zu tun? Ich habe einige Leute gesehen, die Redis benutzen, einige Leute, die ihre normale Datenbank verwenden (MySQL oder Postgres oder was auch immer), einige Leute, die memcached benutzen.
Die Anwendung, an der ich arbeite, wird nicht Millionen von Benutzern gleichzeitig haben, oder vielleicht sogar Tausende. Es wird jedoch notwendig sein, ein einigermaßen komplexes Autorisierungsschema zu erhalten. Was ich suche, ist, dass wir nicht etwas "Seltsames" tun, das einen anderen Weg geht als die allgemeine Tornado-Community, da Authentifizierung und Autorisierung, obwohl es etwas ist, was wir brauchen, nicht etwas ist, was es ist der Kern unseres Produktes und deshalb sollten wir uns nicht unterscheiden. Wir suchen also, was die meisten Leute (die Tornado benutzen) in dieser Hinsicht tun, daher denke ich, dass es eine Frage ist mit (theoretisch) einer objektiv wahren Antwort.
Die ideale Antwort würde natürlich auf Beispielcode verweisen.
Tornado ist staatenlos und bietet keine Session-Unterstützung.
Verwenden Sie sichere Cookies, um vertrauliche Informationen wie die Benutzer-ID zu speichern. Verwenden Sie Standard-Cookies, um nicht kritische Informationen zu speichern.
Zum Speichern großer Objekte - verwenden Sie das Standardschema - MySQL + memcache.
So sieht es aus, als ob andere Mikro-Frameworks Sitzungen behandeln (CherryPy, Flask zum Beispiel):
session_id und allen anderen Feldern, die Sie pro Sitzung verfolgen möchten. In einigen Frameworks können Sie diese Informationen nur für einzelne Benutzer in einer Datei speichern oder sie direkt im Speicher ablegen. Wenn Ihre Anwendung klein genug ist, können Sie diese Optionen ebenfalls in Betracht ziehen, aber eine Datenbank sollte einfacher zu implementieren sein. RequestHandler initialize() Funktion, denke ich?) und es kein session_id-Cookie gibt, setze eine sichere Session-ID mit einem Zufallsgenerator. Ich habe nicht viel Erfahrung mit Tornado, aber es scheint, als ob das Setzen eines sicheren Cookies dafür nützlich sein sollte. Speichern Sie das session_id und die zugehörigen Informationen in Ihrer Sitzungstabelle. Beachten Sie, dass JEDER Benutzer eine Sitzung hat, auch wenn diese nicht angemeldet sind. Wenn sich ein Benutzer anmeldet, möchten Sie seinen Status als eingeloggt (und ihren Benutzernamen / Benutzer-ID usw.) an ihre Sitzung anhängen. RequestHandler initialize ein Cookie session_id vorhanden ist, lesen Sie die Informationen zu Ihrer Sitzung aus der Datenbank und erstellen Sie möglicherweise Ihr eigenes Session-Objekt, das als Membervariable dieses Request-Handlers gefüllt und gespeichert wird / li>
Denken Sie daran, dass die Sitzungen nach einer bestimmten Inaktivitätsphase ablaufen sollten, also sollten Sie auch danach suchen. Wenn Sie sich in einer "sich merken" -Menge anmelden möchten, müssen Sie ein sicheres Cookie verwenden, um dies zu signalisieren (lesen Sie dies bei OWASP, um sicherzustellen, dass es so sicher wie möglich ist), dachte Tornado's secret_cookie könnte helfen Wenn Sie eine zeitgesteuerte Sitzung erhalten, können Sie einen neuen Benutzer erneut authentifizieren, indem Sie eine neue Sitzung erstellen und die zugehörigen Informationen aus der alten Sitzung in die neue übertragen.
Das Hauptproblem bei Sitzungen ist nicht, wo sie gespeichert werden sollen, sondern wie sie intelligent ablaufen können. Unabhängig davon, wo die Sitzungen gespeichert sind, werden alle diese Daten in den RAM passen und schnell bedient werden, solange die Anzahl der gespeicherten Sitzungen vernünftig ist (d. H. Nur aktive Sitzungen plus einige Überschüsse werden gespeichert). Wenn es viel alten Müll gibt, können Sie unvorhersehbare Verzögerungen erwarten (die Festplatte muss zum Laden der Sitzung gedrückt werden).
Zu diesem Zweck ist nichts direkt in Tornado integriert. Wie andere bereits erwähnt haben, ist Tornado als sehr schnelles asynchrones Framework konzipiert. Es ist schlank von Design. Es ist jedoch möglich, eigene Sitzungsverwaltungsfunktionen einzubinden. Sie müssen jedem Handler, der einen Sitzungscontainer erstellen oder abrufen würde, einen Präambelabschnitt hinzufügen. Sie müssen die Sitzungs-ID in einem Cookie speichern. Wenn Sie nicht unbedingt HTTPS verwenden, sollten Sie ein sicheres Cookie verwenden. Die Sitzungspersistenz kann jede Technologie Ihrer Wahl sein, wie Redis, Postgres, MySQL, ein Dateispeicher, etc ...
Es gibt ein Github-Projekt, das Sitzungsverwaltung für Tornado bereitstellt. Selbst wenn Sie sich entscheiden, es nicht zu verwenden, kann es einen Einblick geben, wie Sie Ihr eigenes Sitzungsmanagement strukturieren können. Das Github-Projekt wird dustdevil genannt. Volle Offenlegung - wir haben das vor einigen Jahren erstellt, finden es aber sehr einfach zu bedienen und haben es heute aktiv genutzt.