devise
v4.9.4
Devise ist eine flexible Authentifizierungslösung für Rails basierend auf Warden. Es:
Es besteht aus 10 Modulen:
Das Devise-Wiki bietet viele zusätzliche Informationen zu Devise, darunter viele Artikel mit Anleitungen und Antworten auf die am häufigsten gestellten Fragen. Bitte durchsuchen Sie das Wiki, nachdem Sie diese README-Datei gelesen haben:
https://github.com/heartcombo/devise/wiki
Wenn Sie ein Problem mit Devise entdecken, würden wir gerne davon erfahren. Wir bitten Sie jedoch, diese Richtlinien zu lesen, bevor Sie einen Fehlerbericht einreichen:
https://github.com/heartcombo/devise/wiki/Bug-reports
Wenn Sie einen sicherheitsrelevanten Fehler entdeckt haben, verwenden Sie bitte NICHT den GitHub Issue Tracker. Senden Sie eine E-Mail an [email protected].
Wenn Sie Fragen, Kommentare oder Bedenken haben, verwenden Sie bitte StackOverflow anstelle des GitHub-Issue-Trackers:
http://stackoverflow.com/questions/tagged/devise
Die veraltete Mailingliste kann weiterhin gelesen werden
https://groups.google.com/group/plataformatec-devise
Sie können die Devise-Dokumentation im RDoc-Format hier ansehen:
http://rubydoc.info/github/heartcombo/devise/main/frames
Wenn Sie Devise mit früheren Versionen von Rails verwenden müssen, können Sie nach der Installation des Gems jederzeit „gem server“ über die Befehlszeile ausführen, um auf die alte Dokumentation zuzugreifen.
Auf GitHub sind einige Beispielanwendungen verfügbar, die verschiedene Funktionen von Devise mit verschiedenen Rails-Versionen demonstrieren. Sie können sie hier ansehen:
https://github.com/heartcombo/devise/wiki/Example-Applications
Unsere Community hat eine Reihe von Erweiterungen erstellt, die über den in Devise enthaltenen Funktionsumfang hinausgehen. Hier können Sie eine Liste der verfügbaren Erweiterungen anzeigen und Ihre eigenen hinzufügen:
https://github.com/heartcombo/devise/wiki/Extensions
Wir hoffen, dass Sie darüber nachdenken, bei Devise mitzuwirken. Bitte lesen Sie diese kurze Übersicht, um einige Informationen zum Einstieg zu erhalten:
https://github.com/heartcombo/devise/wiki/Contributing
Normalerweise möchten Sie Tests für Ihre Änderungen schreiben. Um die Testsuite auszuführen, gehen Sie in das oberste Verzeichnis von Devise und führen Sie bundle install und bin/test aus. Devise funktioniert mit mehreren Ruby- und Rails-Versionen sowie ActiveRecord- und Mongoid-ORMs, was bedeutet, dass Sie die Testsuite mit einigen Modifikatoren ausführen können: DEVISE_ORM und BUNDLE_GEMFILE .
Da Devise sowohl Mongoid als auch ActiveRecord unterstützt, verlassen wir uns auf diese Variable, um für jedes ORM spezifischen Code auszuführen. Der Standardwert von DEVISE_ORM ist active_record . Um die Tests für Mongoid auszuführen, können Sie mongoid bestehen:
DEVISE_ORM=mongoid bin/test
==> Devise.orm = :mongoid
Wenn Sie die Tests für Mongoid ausführen, muss auf Ihrem System ein MongoDB-Server (Version 2.0 oder neuer) ausgeführt werden.
Bitte beachten Sie, dass in der Befehlsausgabe der verwendete Variablenwert angezeigt wird.
Wir können diese Variable verwenden, um dem Bundler mitzuteilen, welche Gemfile er verwenden soll (anstelle der im aktuellen Verzeichnis). Im gemfiles-Verzeichnis haben wir eine für jede von uns unterstützte Rails-Version. Wenn Sie uns eine Pull-Anfrage senden, kann es vorkommen, dass die Testsuite bei der Verwendung einiger davon nicht mehr funktioniert. Wenn dies der Fall ist, können Sie dieselbe Umgebung mithilfe der Variablen BUNDLE_GEMFILE simulieren. Wenn die Tests beispielsweise mit Ruby 3.0.0 und Rails 6.0 fehlgeschlagen sind, können Sie Folgendes tun:
rbenv shell 3.0.0 # or rvm use 3.0.0
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bin/testSie können auch beides kombinieren, wenn die Tests für Mongoid fehlgeschlagen sind:
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 DEVISE_ORM=mongoid bin/testDevise verwendet Mini Test als Testframework.
bin/testbin/test test/models/trackable_test.rbbin/test test/models/trackable_test.rb:16Wenn Sie Ihre erste Rails-Anwendung erstellen, empfehlen wir Ihnen, Devise nicht zu verwenden. Devise erfordert ein gutes Verständnis des Rails Frameworks. In solchen Fällen empfehlen wir Ihnen, ein einfaches Authentifizierungssystem von Grund auf neu zu starten. Hier sind ein paar Ressourcen, die Ihnen den Einstieg erleichtern sollen:
Sobald Sie Ihr Verständnis von Rails und Authentifizierungsmechanismen gefestigt haben, können wir Ihnen versichern, dass die Zusammenarbeit mit Devise sehr angenehm sein wird. ?
Devise 4.0 funktioniert mit Rails 6.0 und höher. Laufen:
bundle add deviseAls nächstes müssen Sie den Generator starten:
rails generate devise:install Zu diesem Zeitpunkt werden in der Konsole eine Reihe von Anweisungen angezeigt. Unter diesen Anweisungen müssen Sie die Standard-URL-Optionen für den Devise-Mailer in jeder Umgebung einrichten. Hier ist eine mögliche Konfiguration für config/environments/development.rb :
config . action_mailer . default_url_options = { host : 'localhost' , port : 3000 }Der Generator installiert einen Initialisierer, der ALLE Konfigurationsoptionen von Devise beschreibt. Es ist unbedingt erforderlich , dass Sie einen Blick darauf werfen. Wenn Sie fertig sind, können Sie Devise mithilfe des Generators zu jedem Ihrer Modelle hinzufügen.
Im folgenden Befehl ersetzen Sie MODEL durch den Klassennamen, der für die Benutzer der Anwendung verwendet wird (häufig ist es User , könnte aber auch Admin lauten). Dadurch wird ein Modell erstellt (falls noch keins vorhanden ist) und es mit den standardmäßigen Devise-Modulen konfiguriert. Der Generator konfiguriert außerdem Ihre Datei config/routes.rb so, dass sie auf den Devise-Controller verweist.
rails generate devise MODELÜberprüfen Sie als Nächstes das MODEL auf zusätzliche Konfigurationsoptionen, die Sie möglicherweise hinzufügen möchten, z. B. bestätigbar oder sperrbar. Wenn Sie eine Option hinzufügen, überprüfen Sie unbedingt die Migrationsdatei (die vom Generator erstellt wird, wenn Ihr ORM diese unterstützt) und kommentieren Sie den entsprechenden Abschnitt aus. Wenn Sie beispielsweise die Option „Bestätigbar“ im Modell hinzufügen, müssen Sie den Abschnitt „Bestätigbar“ in der Migration auskommentieren.
Führen Sie dann rails db:migrate aus
Sie sollten Ihre Anwendung neu starten, nachdem Sie die Konfigurationsoptionen von Devise geändert haben (dazu gehört auch das Stoppen von Spring). Andernfalls stoßen Sie auf seltsame Fehler, z. B. darauf, dass Benutzer sich nicht anmelden können und Routenhelfer nicht definiert sind.
Devise erstellt einige Hilfsprogramme, die Sie in Ihren Controllern und Ansichten verwenden können. Um einen Controller mit Benutzerauthentifizierung einzurichten, fügen Sie einfach diese before_action hinzu (vorausgesetzt, Ihr Gerätemodell ist „Benutzer“):
before_action :authenticate_user! Beachten Sie für Rails 5, dass protect_from_forgery nicht mehr der before_action -Kette vorangestellt wird. Wenn Sie also authenticate_user vor protect_from_forgery “ festgelegt haben, wird Ihre Anfrage zu „Die Authentizität des CSRF-Tokens kann nicht überprüft werden“ führen. Um dieses Problem zu beheben, ändern Sie entweder die Reihenfolge, in der Sie sie aufrufen, oder verwenden Sie protect_from_forgery prepend: true .
Wenn Ihr Gerätemodell etwas anderes als „Benutzer“ ist, ersetzen Sie „_user“ durch „_yourmodel“. Die gleiche Logik gilt für die folgenden Anweisungen.
Um zu überprüfen, ob ein Benutzer angemeldet ist, verwenden Sie den folgenden Helfer:
user_signed_in?Für den aktuell angemeldeten Benutzer ist dieser Helfer verfügbar:
current_userSie können auf die Sitzung für diesen Bereich zugreifen:
user_session Nach der Anmeldung eines Benutzers, der Bestätigung des Kontos oder der Aktualisierung des Passworts sucht Devise nach einem begrenzten Root-Pfad für die Weiterleitung. Wenn Sie beispielsweise eine :user -Ressource verwenden, wird der user_root_path verwendet, sofern vorhanden. andernfalls wird der Standard root_path verwendet. Das bedeutet, dass Sie den Stamm innerhalb Ihrer Routen festlegen müssen:
root to : 'home#index' Sie können auch after_sign_in_path_for und after_sign_out_path_for überschreiben, um Ihre Weiterleitungs-Hooks anzupassen.
Beachten Sie, dass, wenn Ihr Devise-Modell beispielsweise Member statt User heißt, folgende Hilfsprogramme verfügbar sind:
before_action :authenticate_member!
member_signed_in?
current_member
member_sessionDie Devise-Methode in Ihren Modellen akzeptiert auch einige Optionen zum Konfigurieren ihrer Module. Sie können beispielsweise die Kosten des Hashing-Algorithmus wählen mit:
devise :database_authenticatable , :registerable , :confirmable , :recoverable , stretches : 13 Neben :stretches können Sie unter anderem :pepper , :encryptor , :confirm_within , :remember_for , :timeout_in , :unlock_in definieren. Weitere Einzelheiten finden Sie in der Initialisierungsdatei, die erstellt wurde, als Sie den oben beschriebenen Generator „devise:install“ aufgerufen haben. Diese Datei befindet sich normalerweise unter /config/initializers/devise.rb .
Die Parameter Sanitizer API hat sich für Devise 4 geändert
Für frühere Devise-Versionen siehe https://github.com/heartcombo/devise/tree/3-stable#strong-parameters
Wenn Sie Ihre eigenen Ansichten anpassen, fügen Sie möglicherweise neue Attribute zu Formularen hinzu. Rails 4 hat die Parameterbereinigung vom Modell auf den Controller verlagert, sodass Devise dieses Problem auch auf dem Controller lösen muss.
In Devise gibt es nur drei Aktionen, die die Weitergabe beliebiger Parametersätze an das Modell ermöglichen und daher eine Bereinigung erfordern. Ihre Namen und standardmäßig zulässigen Parameter sind:
sign_in ( Devise::SessionsController#create ) – Lässt nur die Authentifizierungsschlüssel zu (wie email )sign_up ( Devise::RegistrationsController#create ) – Erlaubt Authentifizierungsschlüssel plus password und password_confirmationaccount_update ( Devise::RegistrationsController#update ) – Ermöglicht Authentifizierungsschlüssel plus password , password_confirmation und current_password Falls Sie zusätzliche Parameter zulassen möchten (Lazy Way™), können Sie dies mit einer einfachen Before-Aktion in Ihrem ApplicationController tun:
class ApplicationController < ActionController :: Base
before_action :configure_permitted_parameters , if : :devise_controller?
protected
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_up , keys : [ :username ] )
end
end Das Obige funktioniert für alle zusätzlichen Felder, bei denen die Parameter einfache Skalartypen sind. Wenn Sie verschachtelte Attribute haben (z. B. Sie verwenden accepts_nested_attributes_for “), müssen Sie devise diese Verschachtelungen und Typen mitteilen:
class ApplicationController < ActionController :: Base
before_action :configure_permitted_parameters , if : :devise_controller?
protected
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_up , keys : [ :first_name , :last_name , address_attributes : [ :country , :state , :city , :area , :postal_code ] ] )
end
endMit Devise können Sie Devise-Standardeinstellungen vollständig ändern oder benutzerdefiniertes Verhalten aufrufen, indem Sie einen Block übergeben:
Verwenden Sie dies, um einfache Skalarwerte für Benutzername und E-Mail zuzulassen
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_in ) do | user_params |
user_params . permit ( :username , :email )
end
endWenn Sie über einige Kontrollkästchen verfügen, die die Rollen ausdrücken, die ein Benutzer bei der Registrierung übernehmen kann, sendet der Browser diese ausgewählten Kontrollkästchen als Array. Ein Array gehört nicht zu den zulässigen Skalaren von Strong Parameters, daher müssen wir Devise wie folgt konfigurieren:
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_up ) do | user_params |
user_params . permit ( { roles : [ ] } , :email , :password , :password_confirmation )
end
endEine Liste der zulässigen Skalare und Informationen zum Deklarieren zulässiger Schlüssel in verschachtelten Hashes und Arrays finden Sie unter
https://github.com/rails/strong_parameters#nested-parameters
Wenn Sie über mehrere Devise-Modelle verfügen, möchten Sie möglicherweise für jedes Modell einen anderen Parameter-Desinfektionsmittel einrichten. In diesem Fall empfehlen wir, von Devise::ParameterSanitizer zu erben und Ihre eigene Logik hinzuzufügen:
class User :: ParameterSanitizer < Devise :: ParameterSanitizer
def initialize ( * )
super
permit ( :sign_up , keys : [ :username , :email ] )
end
endUnd dann konfigurieren Sie Ihre Controller für die Verwendung:
class ApplicationController < ActionController :: Base
protected
def devise_parameter_sanitizer
if resource_class == User
User :: ParameterSanitizer . new ( User , :user , params )
else
super # Use the default one
end
end
end Das obige Beispiel überschreibt die zulässigen Parameter für den Benutzer, sodass sie sowohl :username als auch :email sind. Die unkomplizierte Möglichkeit, Parameter zu konfigurieren, wäre die Definition des oben genannten Vorher-Filters in einem benutzerdefinierten Controller. In den folgenden Abschnitten erfahren Sie, wie Sie Controller konfigurieren und anpassen.
Wir haben Devise entwickelt, um Ihnen bei der schnellen Entwicklung einer Anwendung zu helfen, die Authentifizierung verwendet. Wir möchten Ihnen jedoch nicht im Weg stehen, wenn Sie es anpassen müssen.
Da es sich bei Devise um eine Engine handelt, sind alle ihre Ansichten im Gem verpackt. Diese Ansichten helfen Ihnen beim Einstieg, aber nach einiger Zeit möchten Sie sie vielleicht ändern. In diesem Fall müssen Sie lediglich den folgenden Generator aufrufen, der alle Ansichten in Ihre Anwendung kopiert:
rails generate devise:views Wenn Sie mehr als ein Devise-Modell in Ihrer Anwendung haben (z. B. User und Admin ), werden Sie feststellen, dass Devise für alle Modelle dieselben Ansichten verwendet. Glücklicherweise bietet Devise eine einfache Möglichkeit, Ansichten anzupassen. Sie müssen lediglich config.scoped_views = true in der Datei config/initializers/devise.rb festlegen.
Anschließend stehen Ihnen Ansichten basierend auf der Rolle zur Verfügung, z. B. users/sessions/new und admins/sessions/new . Wenn im Bereich keine Ansicht gefunden wird, verwendet Devise die Standardansicht unter devise/sessions/new . Sie können den Generator auch verwenden, um bereichsbezogene Ansichten zu generieren:
rails generate devise:views users Wenn Sie nur wenige Ansichtensätze generieren möchten, z. B. die für das registerable und confirmable Modul, können Sie mit dem Flag -v eine Liste von Ansichten an den Generator übergeben.
rails generate devise:views -v registrations confirmationsWenn die Anpassung auf der Ansichtsebene nicht ausreicht, können Sie jeden Controller anpassen, indem Sie die folgenden Schritte ausführen:
Erstellen Sie Ihre benutzerdefinierten Controller mit dem Generator, der einen Bereich erfordert:
rails generate devise:controllers [scope] Wenn Sie users als Bereich angeben, werden Controller in app/controllers/users/ erstellt. Und der Sitzungscontroller sieht so aus:
class Users :: SessionsController < Devise :: SessionsController
# GET /resource/sign_in
# def new
# super
# end
...
end Verwenden Sie das Flag -c , um einen oder mehrere Controller anzugeben, zum Beispiel: rails generate devise:controllers users -c sessions
Weisen Sie den Router an, diesen Controller zu verwenden:
devise_for :users , controllers : { sessions : 'users/sessions' } Empfohlen, aber nicht erforderlich: Kopieren (oder verschieben) Sie die Ansichten von devise/sessions nach users/sessions . Rails verwendet aufgrund der Vererbung weiterhin die Ansichten von devise/sessions , wenn Sie diesen Schritt überspringen. Wenn die Ansichten jedoch mit den Controllern übereinstimmen, bleibt die Konsistenz erhalten.
Abschließend ändern oder erweitern Sie die gewünschten Controller-Aktionen.
Sie können eine Controller-Aktion vollständig überschreiben:
class Users :: SessionsController < Devise :: SessionsController
def create
# custom sign-in code
end
endOder Sie können einfach neues Verhalten hinzufügen:
class Users :: SessionsController < Devise :: SessionsController
def create
super do | resource |
BackgroundWorker . trigger ( resource )
end
end
endDies ist nützlich, um Hintergrundjobs auszulösen oder Ereignisse bei bestimmten Aktionen zu protokollieren.
Denken Sie daran, dass Devise Flash-Nachrichten verwendet, um Benutzer darüber zu informieren, ob die Anmeldung erfolgreich war oder nicht. Devise erwartet, dass Ihre Anwendung entsprechend flash[:notice] und flash[:alert] aufruft. Drucken Sie nicht den gesamten Flash-Hash, sondern nur bestimmte Schlüssel. Unter bestimmten Umständen fügt Devise dem Flash-Hash einen :timedout Schlüssel hinzu, der nicht zur Anzeige gedacht ist. Entfernen Sie diesen Schlüssel aus dem Hash, wenn Sie beabsichtigen, den gesamten Hash zu drucken.
Devise wird auch mit Standardrouten ausgeliefert. Wenn Sie sie anpassen müssen, sollten Sie dies wahrscheinlich über die Methode devise_for tun können. Es akzeptiert mehrere Optionen wie :class_name, :path_prefix usw., einschließlich der Möglichkeit, Pfadnamen für I18n zu ändern:
devise_for :users , path : 'auth' , path_names : { sign_in : 'login' , sign_out : 'logout' , password : 'secret' , confirmation : 'verification' , unlock : 'unblock' , registration : 'register' , sign_up : 'cmon_let_me_in' } Weitere Informationen finden Sie in der Dokumentation devise_for .
Wenn Sie tiefergehende Anpassungen benötigen, um beispielsweise neben „/users/sign_in“ auch „/sign_in“ zuzulassen, müssen Sie Ihre Routen lediglich normal erstellen und sie in einen devise_scope Block im Router einschließen:
devise_scope :user do
get 'sign_in' , to : 'devise/sessions#new'
end Auf diese Weise weisen Sie Devise an, den Bereich :user zu verwenden, wenn auf „/sign_in“ zugegriffen wird. Beachten Sie, devise_scope as den Aliasnamen Ihres Routers hat.
Bitte beachten Sie: Sie müssen Ihren Routen weiterhin devise_for hinzufügen, um Hilfsmethoden wie current_user verwenden zu können.
devise_for :users , skip : :allDevise lässt sich in Hotwire/Turbo integrieren, indem es solche Anfragen als Navigationsanfragen behandelt und bestimmte Antworten auf Fehler und Weiterleitungen so konfiguriert, dass sie dem erwarteten Verhalten entsprechen. Neue Apps werden standardmäßig mit der folgenden Antwortkonfiguration generiert, und bestehende Apps können sich dafür entscheiden, indem sie die Konfiguration zu ihren Devise-Initialisierern hinzufügen:
Devise . setup do | config |
# ...
# When using Devise with Hotwire/Turbo, the http status for error responses
# and some redirects must match the following. The default in Devise for existing
# apps is `200 OK` and `302 Found` respectively, but new apps are generated with
# these new defaults that match Hotwire/Turbo behavior.
# Note: These might become the new default in future versions of Devise.
config . responder . error_status = :unprocessable_entity
config . responder . redirect_status = :see_other
end Wichtig : Für diese benutzerdefinierten Antworten muss die Gem-Version responders 3.1.0 oder höher sein. Bitte stellen Sie sicher, dass Sie sie aktualisieren, wenn Sie diese Konfiguration verwenden möchten. Weitere Informationen finden Sie in dieser Upgrade-Anleitung.
Hinweis : Die obige Statuskonfiguration kann in einer zukünftigen Version zur Standardeinstellung für Devise werden.
Es gibt noch ein paar weitere Änderungen, die Sie möglicherweise an Ihrer App vornehmen müssen, damit sie mit Hotwire/Turbo funktioniert, wenn Sie von Rails-UJs migrieren:
data-confirm , die den Schaltflächen/Formularen vor der Übermittlung ein Bestätigungsmodalität hinzufügt, muss in data-turbo-confirm geändert werden, damit Turbo diese ordnungsgemäß verarbeitet.data-method , die die Anforderungsmethode für Linkübermittlungen festlegt, muss in data-turbo-method geändert werden. Dies ist für button_to oder form s nicht erforderlich, da Turbo damit umgehen kann. Wenn Sie Devise so einrichten, dass es sich über :delete abmeldet, und Sie Links (anstelle von in ein Formular eingeschlossenen Schaltflächen) verwenden, um sich mit der Option method: :delete abzumelden, müssen diese wie oben beschrieben aktualisiert werden. (Devise stellt in seinen freigegebenen Ansichten keine Links/Schaltflächen zum Abmelden bereit.)
Überprüfen Sie unbedingt Ihre Ansichten auf diese und ändern Sie sie entsprechend.
Devise verwendet Flash-Nachrichten mit I18n in Verbindung mit den Flash-Tasten :notice und :alert. Um Ihre App anzupassen, können Sie Ihre Gebietsschemadatei einrichten:
en :
devise :
sessions :
signed_in : ' Signed in successfully. 'Sie können auch unterschiedliche Nachrichten basierend auf der von Ihnen konfigurierten Ressource erstellen, indem Sie den in „Routes“ angegebenen eindeutigen Namen verwenden:
en :
devise :
sessions :
user :
signed_in : ' Welcome user, you are signed in. '
admin :
signed_in : ' Hello admin! 'Der Devise-Mailer verwendet ein ähnliches Muster, um Betreffnachrichten zu erstellen:
en :
devise :
mailer :
confirmation_instructions :
subject : ' Hello everybody! '
user_subject : ' Hello User! Please confirm your email '
reset_password_instructions :
subject : ' Reset instructions 'Schauen Sie sich unsere Locale-Datei an, um alle verfügbaren Nachrichten zu überprüfen. Vielleicht interessieren Sie sich auch für eine der vielen Übersetzungen, die in unserem Wiki verfügbar sind:
https://github.com/heartcombo/devise/wiki/I18n
Achtung: Devise-Controller erben von ApplicationController. Wenn Ihre App mehrere Gebietsschemas verwendet, sollten Sie unbedingt I18n.locale in ApplicationController festlegen.
Devise enthält einige Testhelfer für Controller- und Integrationstests. Um sie nutzen zu können, müssen Sie das entsprechende Modul in Ihre Testfälle/Spezifikationen einbinden.
Controller-Tests erfordern, dass Sie Devise::Test::IntegrationHelpers in Ihren Testfall oder die übergeordnete ActionController::TestCase Superklasse einschließen. Fügen Sie für Rails-Versionen vor 5 stattdessen Devise::Test::ControllerHelpers ein, da die Superklasse für Controller-Tests in ActionDispatch::IntegrationTest geändert wurde (weitere Einzelheiten finden Sie im Abschnitt Integrationstests).
class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: IntegrationHelpers # Rails >= 5
end class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: ControllerHelpers # Rails < 5
end Wenn Sie RSpec verwenden, können Sie Folgendes in eine Datei mit dem Namen spec/support/devise.rb oder in Ihre spec/spec_helper.rb (oder spec/rails_helper.rb wenn Sie rspec-rails verwenden) einfügen:
RSpec . configure do | config |
config . include Devise :: Test :: ControllerHelpers , type : :controller
config . include Devise :: Test :: ControllerHelpers , type : :view
end Stellen Sie jedoch sicher, dass diese Einbindung nach der require 'rspec/rails' erfolgt.
Jetzt können Sie die Methoden sign_in und sign_out für Ihre Controller-Tests verwenden:
sign_in @user
sign_in @user , scope : :adminWenn Sie interne Devise-Controller oder einen Controller testen, der von Devise erbt, müssen Sie Devise vor einer Anfrage mitteilen, welche Zuordnung verwendet werden soll. Dies ist notwendig, da Devise diese Informationen vom Router erhält. Da Controller-Tests jedoch nicht über den Router erfolgen, muss dies explizit angegeben werden. Wenn Sie beispielsweise den Benutzerbereich testen, verwenden Sie einfach:
test 'GET new' do
# Mimic the router behavior of setting the Devise scope through the env.
@request . env [ 'devise.mapping' ] = Devise . mappings [ :user ]
# Use the sign_in helper to sign in a fixture `User` record.
sign_in users ( :alice )
get :new
# assert something
end Integrationstest-Helfer sind verfügbar, indem Sie das Modul Devise::Test::IntegrationHelpers einbinden.
class PostsTests < ActionDispatch :: IntegrationTest
include Devise :: Test :: IntegrationHelpers
end Jetzt können Sie die folgenden sign_in und sign_out -Methoden in Ihren Integrationstests verwenden:
sign_in users ( :bob )
sign_in users ( :bob ) , scope : :admin
sign_out :user RSpec-Benutzer können das IntegrationHelpers Modul in ihre :feature -Spezifikationen einbinden.
RSpec . configure do | config |
config . include Devise :: Test :: IntegrationHelpers , type : :feature
end Im Gegensatz zu Controller-Tests müssen Integrationstests nicht den env devise.mapping bereitstellen, da die Zuordnung durch die in Ihren Tests ausgeführten Routen abgeleitet werden kann.
Weitere Informationen zum Testen Ihrer Rails-Controller mit RSpec finden Sie im Wiki:
Devise bietet standardmäßig OmniAuth-Unterstützung für die Authentifizierung bei anderen Anbietern. Um es zu verwenden, geben Sie einfach Ihre OmniAuth-Konfiguration in config/initializers/devise.rb :
config . omniauth :github , 'APP_ID' , 'APP_SECRET' , scope : 'user,public_repo'Weitere Informationen zur OmniAuth-Unterstützung finden Sie im Wiki:
Mit Devise können Sie beliebig viele Devise-Modelle einrichten. Wenn Sie zusätzlich zum oben genannten Benutzermodell ein Admin-Modell mit nur Authentifizierungs- und Timeout-Funktionen haben möchten, führen Sie einfach Folgendes aus:
# Create a migration with the required fields
create_table :admins do | t |
t . string :email
t . string :encrypted_password
t . timestamps null : false
end
# Inside your Admin model
devise :database_authenticatable , :timeoutable
# Inside your routes
devise_for :admins
# Inside your protected controller
before_action :authenticate_admin!
# Inside your controllers and views
admin_signed_in?
current_admin
admin_sessionAlternativ können Sie einfach den Devise-Generator ausführen.
Bedenken Sie, dass diese Modelle völlig unterschiedliche Routen haben. Sie können und können nicht denselben Controller zum Anmelden, Abmelden usw. verwenden. Wenn Sie möchten, dass unterschiedliche Rollen dieselben Aktionen gemeinsam nutzen, empfehlen wir die Verwendung eines rollenbasierten Ansatzes, indem Sie entweder eine Rollenspalte bereitstellen oder ein dediziertes Gem für die Autorisierung verwenden.
Wenn Sie Active Job verwenden, um Action Mailer-Nachrichten im Hintergrund über ein Warteschlangen-Back-End zuzustellen, können Sie Devise-E-Mails über Ihre vorhandene Warteschlange senden, indem Sie die Methode send_devise_notification in Ihrem Modell überschreiben.
def send_devise_notification ( notification , * args )
devise_mailer . send ( notification , self , * args ) . deliver_later
endWenn Sie das Modul „Wiederherstellbar“ aktivieren, beachten Sie, dass ein gestohlenes Passwort-Reset-Token einem Angreifer Zugriff auf Ihre Anwendung verschaffen könnte. Devise unternimmt große Anstrengungen, um zufällige, sichere Token zu generieren, und speichert nur Token-Digests in der Datenbank, niemals Klartext. Das standardmäßige Protokollierungsverhalten in Rails kann jedoch dazu führen, dass Klartext-Token in Protokolldateien gelangen:
deliver_later zum Senden von E-Mails zum Zurücksetzen des Passworts verwendet wird, werden Passwort-Reset-Tokens durchgesickert. Rails setzt die Produktions-Logger-Ebene standardmäßig auf INFO. Wenn Sie verhindern möchten, dass Token in Ihre Protokolle gelangen, sollten Sie die Stufe Ihres Produktions-Loggers auf „WARN“ ändern. In config/environments/production.rb :
config . log_level = :warnDevise unterstützt ActiveRecord (Standard) und Mongoid. Um einen anderen ORM auszuwählen, fordern Sie ihn einfach in der Initialisierungsdatei an.
Rails 5+ verfügt über einen integrierten API-Modus, der Rails (nur) für die Verwendung als API optimiert. Devise ist einigermaßen in der Lage, in diesem Modus erstellte Anwendungen ohne zusätzliche Änderungen zu verarbeiten, in dem Sinne, dass es keine Ausnahmen und dergleichen auslösen sollte. Während development / testing können jedoch dennoch einige Probleme auftreten, da wir noch nicht das volle Ausmaß dieser Kompatibilität kennen. (Weitere Informationen finden Sie in Problem Nr. 4947)
Nur-API-Anwendungen unterstützen keine browserbasierte Authentifizierung über Cookies, was die Standardeinstellung des Geräts ist. Dennoch kann Devise in diesen Fällen mit der http_authenticatable -Strategie, die HTTP Basic Auth verwendet und den Benutzer bei jeder Anfrage authentifiziert, immer noch eine sofort einsatzbereite Authentifizierung bereitstellen. (Weitere Informationen finden Sie in diesem Wiki-Artikel zur Vorgehensweise: Verwenden der HTTP-Basisauthentifizierung.)
Der Gerätestandard für HTTP-Authentifizierung ist deaktiviert, daher muss er im Geräteinitialisierer für die Datenbankstrategie aktiviert werden:
config . http_authenticatable = [ :database ]Diese Einschränkung hindert Sie nicht daran, benutzerdefinierte Warden-Strategien zu implementieren, weder in Ihrer Anwendung noch über gem-basierte Erweiterungen für Geräte. Eine gängige Authentifizierungsstrategie für APIs ist die tokenbasierte Authentifizierung. Weitere Informationen zum Erweitern von Devise zur Unterstützung dieser und anderer Authentifizierungsarten finden Sie im Wiki-Artikel „Beispiele und Alternativen zur einfachen Token-Authentifizierung“ oder in diesem Blogbeitrag zu benutzerdefinierten Authentifizierungsmethoden mit Devise.
Der API-Modus ändert die Reihenfolge des Middleware-Stacks, was zu Problemen für Devise::Test::IntegrationHelpers führen kann. Dieses Problem tritt normalerweise als undefined method `[]=' for nil:NilClass auf, wenn Integrationstest-Hilfsprogramme wie #sign_in verwendet werden. Die Lösung besteht einfach darin, die Middleware neu anzuordnen, indem Sie Folgendes zu test.rb hinzufügen:
Rails . application
