Für jeden Benutzer in der Rails-Anwendung wird ein Sitzungsobjekt erstellt, und die vorherigen Anforderungsinformationen können kontinuierlich verwendet werden. Sitzungen sind nur in "Controller" und "Ansicht" verfügbar, und eine kleine Datenmenge wird in der Sitzung gespeichert.
Sie können aus den folgenden Speicherzielen für die Sitzung auswählen.
--ActionDispatch :: Session :: CookieStore: Speichern Sie alle Sitzungen im Cookie des clientseitigen Browsers
--ActionDispatch :: Session :: CacheStore: Daten im Rails-Cache speichern
--ActionDispatch :: Session :: ActiveRecordStore: Mit Active Record in der Datenbank speichern (erfordert den Edelstein activerecord-session_store)
--ActionDispatch :: Session :: MemCacheStore: Speichern Sie Daten in einem zwischengespeicherten Cluster (diese Implementierung ist alt und Sie sollten CacheStore in Betracht ziehen).
Die Sitzung hat eine eindeutige ID und speichert sie in "Cookie". Das Übergeben der Sitzungs-ID als "URL" ist aus Sicherheitsgründen sehr gefährlich, daher lässt "Rails" dies standardmäßig nicht zu. Daher muss die Sitzungs-ID als "Cookie" übergeben werden.
Viele SessionStore (Sitzungs-IDs) werden zum Abrufen von Sitzungsdaten auf dem Server verwendet.
Allerdings speichert nur "CookieStore" alle Sitzungsdaten in "Cookie" selbst (Sitzungs-ID kann bei Bedarf verwendet werden).
CookieStore wird standardmäßig in Rails verwendet und ist der empfohlene Sitzungsspeicher in Rails.
Der Vorteil von "CookieStore" ist
Die "Cookie" -Daten erhalten eine verschlüsselte Signatur, um Manipulationen zu verhindern, und das Cookie selbst wird verschlüsselt, sodass der Inhalt von anderen gelesen wird. (Der manipulierte "Cookie" wird von "Rails" abgelehnt.)
Im CookieStore können ca. 4 KB Daten gespeichert werden, was einer ausreichenden Kapazität entspricht. Unabhängig von der Art des verwendeten Sitzungsspeichers ist es nicht wünschenswert, eine große Datenmenge in einer Sitzung zu speichern.
Betrachten Sie "ActionDispatch :: Session :: CacheStore", wenn Ihre Benutzersitzung keine wichtigen Daten enthält oder wenn Sie Ihre Sitzung nicht lange speichern müssen.
Der Vorteil besteht darin, dass die vorhandene Cache-Infrastruktur unverändert verwendet werden kann, da sie mithilfe der in der Webanwendung festgelegten Cache-Implementierung gespeichert wird. Daher ist keine spezielle Vorbereitung erforderlich.
Der Nachteil ist, dass die Sitzung nur von kurzer Dauer ist und jederzeit verschwinden kann.
Der Zugriff auf die Sitzung wird über die Instanzmethode "session" in der Steuerung ermöglicht. Sitzungswerte werden mithilfe von Hash-ähnlichen Schlüssel / Wert-Paaren gespeichert.
class ApplicationController < ActionController::Base
private
#Suchen Sie nach Benutzern anhand der in einer Schlüsselsitzung gespeicherten ID
# :current_user_id ist eine Standardmethode für Benutzeranmeldungen in Rails-Anwendungen.
#Wenn Sie sich anmelden, wird der Sitzungswert festgelegt und
#Der Sitzungswert wird beim Abmelden gelöscht.
<Methode ①>
def current_user
@current_user ||= session[:current_user_id] &&
User.find_by(id: session[:current_user_id])
end
<Methode ②>
def current_user
if session[:current_user_id]
@current_user ||= User.find_by(id: session[:current_user_id])
end
end
end
Wenn Sie etwas in der Sitzung speichern möchten, weisen Sie einen Schlüssel wie einen Hash zu.
class LoginsController < ApplicationController
# "Create" a login, aka "log the user in"
def create
if user = User.authenticate(params[:username], params[:password])
#Speichern Sie die Sitzungsbenutzer-ID und
#Stellen Sie es für zukünftige Anfragen zur Verfügung
session[:current_user_id] = user.id
redirect_to root_url
end
end
end
Wenn Sie einige Daten aus der Sitzung entfernen möchten, löschen Sie dieses Schlüssel-Wert-Paar.
class LoginsController < ApplicationController
#Login löschen(=Ausloggen)
def destroy
#Entfernen Sie die Benutzer-ID aus der Sitzungs-ID
session.delete(:current_user_id)
#Löschen Sie den aktuellen Benutzer, der notiert wurde
@_current_user = nil
redirect_to root_url
end
end
Verwenden Sie reset_session, um die gesamte Sitzung zurückzusetzen.
5-2. Flash
flash ist ein spezieller Teil der Sitzung, der bei jeder Anfrage gelöscht wird. Es hat eine Funktion, auf die nur unmittelbar nach der Anforderung verwiesen werden kann, und eine Fehlermeldung wird an view übergeben.
Auf "Flash" wird als Hash zugegriffen und als "FlashHash" -Instanz bezeichnet.
Lassen Sie uns als Beispiel die Abmeldung behandeln. Durch Verwendung von Flash auf dem Controller können Sie die Nachricht senden, die bei der nächsten Anforderung angezeigt werden soll.
class LoginsController < ApplicationController
def destroy
session.delete(:current_user_id)
flash[:notice] = "You have successfully logged out."
redirect_to root_url
end
end
Die "Flash" -Nachricht kann auch als Teil der Umleitung zugewiesen werden. Zusätzlich zu den Optionen : Notice und: alert kann auch das allgemeine: flash verwendet werden.
redirect_to root_url, notice: "You have successfully logged out."
redirect_to root_url, alert: "You're stuck here!"
redirect_to root_url, flash: { referral_code: 1234 }
class CommentsController < ApplicationController
def new
#Wenn der Name des Kommentars im Cookie verbleibt, wird er automatisch in das Feld eingegeben
@comment = Comment.new(author: cookies[:commenter_name])
end
def create
@comment = Comment.new(params[:comment])
if @comment.save
flash[:notice] = "Thanks for your comment!"
if params[:remember_name]
#Kommentar Speichern Sie den Autorennamen
cookies[:commenter_name] = @comment.author
else
#Kommentar Löschen Sie den Namen des Autors, wenn er im Cookie verbleibt
cookies.delete(:commenter_name)
end
redirect_to @comment.article
else
render action: "new"
end
end
end
Beim Löschen einer Sitzung wurde diese durch Angabe von "nil" als Schlüssel gelöscht. Beim Löschen von "Cookies" müssen Sie jedoch anstelle dieser Methode "cookies.delete (: key)" verwenden.
Rails kann auch signierte Cookie Jar und verschlüsselte Cookie Jar verwenden, um vertrauliche Daten zu speichern.
cookie jar fügt eine Signatur hinzu und verschlüsselt den Wert selbst, sodass er vom Endbenutzer nicht gelesen werden kann.Diese speziellen Cookies verwenden einen Serializer, um den Wert in eine Zeichenfolge zu konvertieren und zu speichern. Führen Sie dann beim Lesen eine umgekehrte Konvertierung ("deserialize") durch, um ihn an ein "Ruby" -Objekt zurückzugeben.
Rails.application.config.action_dispatch.cookies_serializer = :json
Der Standard-Serializer für neue Anwendungen ist : json.
Es wird empfohlen, nur "einfache Daten" wie Zeichenfolgen und Zahlen in "Cookies" zu speichern. Wenn Sie ein komplexes Objekt in "Cookie" speichern müssen, müssen Sie sich um die Konvertierung kümmern, wenn Sie den Wert aus "Cookie" in einer nachfolgenden Anforderung lesen.
Gleiches gilt für "Session" - und "Flash" -Hashes, wenn der "Cookie" -Sitzungsspeicher verwendet wird.
Dank "ActionController" ist es sehr einfach, "XML" -Daten und "JSON" -Daten auszugeben (zu rendern). Die mit "Gerüst" erzeugte Steuerung ist wie folgt.
class UsersController < ApplicationController
def index
@users = User.all
respond_to do |format|
format.html # index.html.erb
format.xml { render xml: @users }
format.json { render json: @users }
end
end
end
Beachten Sie, dass im obigen Code "render xml: @ users" anstelle von "render xml: @ users.to_xml" steht. Rails ruft automatisch to_xml auf, wenn das Objekt nicht vom Typ String ist.
.to_xml
Eine Methode zum Konvertieren eines Arrays oder Hashs in das XML-Format.
array.to_xml([Möglichkeit])
hassh.to_xml([Möglichkeit])
Ein Filter ist eine Methode, die "vor", "nach" oder "unmittelbar vor und um" einer Aktion in der Steuerung ausgeführt wird.
Der Filter wird vererbt. Wenn Sie den Filter in ApplicationController festlegen, wird der Filter in allen Controllern der Anwendung aktiviert.
Eine häufige Verwendung von "Vorher" -Filtern besteht darin, dass sich ein Benutzer anmelden muss, bevor eine Aktion ausgeführt wird. Diese Filtermethode sieht folgendermaßen aus:
class ApplicationController < ActionController::Base
before_action :require_login
private
def require_login
unless logged_in?
flash[:error] = "You must be logged in to access this section"
redirect_to new_login_url # halts request cycle
end
end
end
Diese Methode ist so einfach wie das Speichern der Fehlermeldung in "Flash" und das Umleiten zum Anmeldeformular, wenn der Benutzer nicht angemeldet ist.
In diesem Beispiel haben wir ApplicationController einen Filter hinzugefügt, damit alle Controller, die ihn erben, betroffen sind. Dies bedeutet, dass Sie sich für jede Funktion Ihrer Anwendung anmelden müssen. Wenn Sie auf jedem Bildschirm der Anwendung eine Authentifizierung anfordern, können Sie den für die Authentifizierung erforderlichen Anmeldebildschirm natürlich nicht anzeigen. Legen Sie daher die Anmeldeanforderung für alle Controller und Aktionen wie diese fest. Sollte nicht. Mit der Methode "skip_before_action" können Sie einen Filter für eine bestimmte Aktion überspringen.
class LoginsController < ApplicationController
skip_before_action :require_login, only: [:new, :create]
end
Auf diese Weise können die Aktionen "Neu" und "Erstellen" des "LoginsController" weiterhin ohne Authentifizierung ausgeführt werden. Sie können die Option : only verwenden, wenn Sie den Filter nur für eine bestimmte Aktion überspringen möchten. Wenn Sie den Filter nicht nur für eine bestimmte Aktion überspringen möchten, verwenden Sie die Option ": Ausnahme". Diese Optionen können auch beim Hinzufügen von Filtern verwendet werden, sodass Sie Filter hinzufügen können, die nur für die Aktion ausgeführt werden, die Sie zuerst ausgewählt haben.
After Filter und Around FilterZusätzlich zum Filter "Vorher" können Sie auch einen Filter verwenden, der nach Ausführung der Aktion ausgeführt wird, oder einen Filter, der sowohl vor als auch nach der Ausführung ausgeführt wird.
Der "After" -Filter ähnelt dem "Before" -Filter, aber im Fall des "After" -Filters wurde die Aktion bereits ausgeführt und auf die Antwortdaten, die an den Client gesendet werden sollen, kann zugegriffen werden. Anders als Filter. Unabhängig davon, wie Sie den "After" -Filter schreiben, wird die Ausführung der Aktion natürlich nicht unterbrochen. Beachten Sie jedoch, dass der "Nach" -Filter erst ausgeführt wird, nachdem die Aktion erfolgreich war, und nicht ausgeführt wird, wenn eine Ausnahme in der Mitte des Anforderungszyklus auftritt.
Wenn Sie einen "Around" -Filter verwenden, müssen Sie irgendwo im Filter einen "Yield" ausführen, um die zugehörige Aktion auszuführen. Dies ähnelt der Funktionsweise der Rack-Middleware.
Stellen Sie sich beispielsweise eine Website mit einem Genehmigungsworkflow für Änderungen vor. Administratoren können diese Änderungen problemlos in der Vorschau anzeigen und innerhalb einer Transaktion genehmigen.
class ChangesController < ApplicationController
around_action :wrap_in_transaction, only: :show
private
def wrap_in_transaction
ActiveRecord::Base.transaction do
begin
yield
ensure
raise ActiveRecord::Rollback
end
end
end
end
Beachten Sie, dass für "Rund" -Filter auch die Bildschirmausgabe (Rendering) in der Arbeit enthalten ist. Insbesondere im obigen Beispiel wird, wenn die Ansicht selbst aus der Datenbank liest (unter Verwendung eines Bereichs usw.), der Lesevorgang innerhalb der Transaktion durchgeführt und die Daten werden in der Vorschau angezeigt.
Sie können auch Ihre eigene Antwort erstellen, ohne "Yield" auszuführen. In diesem Fall werden keine Maßnahmen ergriffen.
Recommended Posts