Wir machen viele Rails-Tutorials. In Bezug auf die in Kapitel 8 behandelte "Sitzung" habe ich diesmal einen Artikel geschrieben, den ich nach meinem eigenen Verständnis organisieren möchte. Da ich ein Anfänger bin, wäre ich Ihnen dankbar, wenn Sie in den Kommentaren auf Fehler hinweisen könnten.
Bei dieser Kommunikation ist die Kommunikation zwischen dem Browser und dem Server für jede Hin- und Rückfahrt unabhängig. Vorherige Informationen können nicht vererbt werden.
Möglicherweise fragen Sie sich jedoch, wann Sie diese Geschichte hören. Wenn die gesamte HTML-Kommunikation unabhängig ist, z. B. auf einer Einkaufsseite, Wenn Sie den Artikel, den Sie kaufen möchten, in den Warenkorb legen, werden die Informationen nicht übertragen Der Warenkorb sollte leer sein, wenn Sie Seiten wechseln.
Also, ** Der Mechanismus der Sitzung besteht darin, die zustandslose HTML-Kommunikation "statusbehaftet" zu machen. ** ** **
Bei dieser Kommunikation tauscht der Browser-Server Informationen aus, indem er der Kommunikation Informationen hinzufügt. Es ist möglich, diesen gesamten Austausch in eine Reihe von Aktionen umzuwandeln.
Im obigen Beispiel können Sie auf der Site, auf der Sie sich als Mitglied angemeldet haben, zu verschiedenen Seiten springen, während Sie die Mitgliedsinformationen beibehalten. Dies ist praktisch, da Sie auf der Einkaufsseite immer mehr Dinge in den Warenkorb legen können.
"Stateful Communication" in HTML besteht aus einem Mechanismus, der als Sitzung bezeichnet wird.
Referenz: Sitzungskommunikation
Wie werden
Sitzungen behandeln nicht immer Cookies, aber sie werden sicherlich häufig verwendet. Rails verwendet standardmäßig auch Cookies, daher gehen wir hier von Cookies aus.
** ① Erster Zugriff ** Die Browserseite greift auf die Serverseite zu. Die Serverseite sendet die Identifikationsinformationen des Browsers (z. B. Anmeldeinformationen), die im HTTP-Header enthalten sind. Der Browser speichert diese Informationen (dies sind die Cookie-Informationen).
** ② Zugriff danach ** Die Browserseite nimmt die gespeicherten Cookie-Informationen in den HTTP-Header auf und sendet sie an die Serverseite. Basierend auf diesen Informationen bestimmt die Serverseite, wer darauf zugegriffen hat.
Auf diese Weise ist das Cookie die Information, die auf der Browserseite gespeichert ist, und durch das Senden einschließlich der Sitzungs-ID kann die Serverseite verstehen, "welche Art von Inhalt haben Sie ausgetauscht?" Ich werde. Übrigens wird der Inhalt der Sitzung selbst von der Webserverseite gehalten, und die Sitzungs-ID im Cookie ist die ID für den Aufruf.
Die Sitzung ist nur vorübergehend und wird grundsätzlich gelöscht, wenn der Browser geschlossen wird.
| Lager | Erläuterung |
|---|---|
| ActionDispatch::Session::CookieStore: | Speichern Sie alle Sitzungen in einem Cookie im clientseitigen Browser |
| ActionDispatch::Session::CacheStore: | Speichern Sie Daten im Rails-Cache |
| ActionDispatch::Session::ActiveRecordStore: | Mit Active Record in der Datenbank speichern(activerecord-session_brauche Laden Juwel) |
| ActionDispatch::Session::MemCacheStore: | Speichern Sie Daten in einem zwischengespeicherten Cluster(Diese Implementierung ist alt, daher sollten Sie CacheStore in Betracht ziehen) |
Wie bereits erläutert, wird die Sitzungs-ID im Wesentlichen in einem Cookie gespeichert und an den Server übergeben.
Für den standardmäßig verwendeten CookieStore werden die ** Sitzungsinformationen selbst auf der Cookie-Seite gespeichert. ** ** **
Der CookieStore bietet die folgenden ** Vorteile **. ・ Sehr leicht ・ Für die Verwendung der Sitzung mit der Webanwendung wurde ein Satz vorbereitet. -Die Cookie-Daten erhalten eine verschlüsselte Signatur, um Manipulationen zu verhindern, und das Cookie selbst wird ebenfalls verschlüsselt, sodass der Inhalt nicht von anderen gelesen werden kann (das manipulierte Cookie wird von Rails abgelehnt).
Es gibt jedoch auch die folgenden ** Nachteile **. ・ Die Obergrenze für Cookies liegt bei 4 KB
Grundsätzlich denke ich, dass es besser ist, den von Rails empfohlenen Cookie Store zu verwenden. Ich dachte, dass es notwendig ist, es entsprechend der Situation richtig zu verwenden.
Referenz: Rails-Guide-Sitzung
Im Folgenden sind alle Vorgänge im Cookie Store aufgeführt, die standardmäßig verwendet werden.
** ・ Eine Sitzung erstellen **
session[:user_id] = @user.id
Die Sitzungsmethode kann mit einem Hashwert festgelegt werden. Durch Festlegen wird ein verschlüsseltes Cookie generiert, das die Informationen dieser Sitzung enthält.
** ・ Siehe Sitzung **
user = User.find(id: session[:user_id])
Informationen zur Sitzung können leicht referenziert werden. Wenn die Sitzungsmethode aufgerufen wird, werden die Cookie-Informationen intern entschlüsselt, und der Wert kann mit session [: symbol] abgerufen werden.
** - Sitzung löschen **
#Alles was du tust ist das gleiche
session[:user_id] = nil
session[:user_id].clear
session.delete(:user_id)
Es ist möglich, mit Null umzuschreiben oder Informationen mit Löschen oder Löschen zu löschen.
Als ich es erneut organisierte, konnte ich die Punkte identifizieren, die ich nicht verstand, und es war erfrischend. Ich möchte weiter am Rails-Tutorial arbeiten.
Recommended Posts