devise
v4.9.4
Devise est une solution d'authentification flexible pour Rails basée sur Warden. Il:
Il est composé de 10 modules :
Le wiki Devise contient de nombreuses informations supplémentaires sur Devise, notamment de nombreux articles pratiques et des réponses aux questions les plus fréquemment posées. Veuillez parcourir le wiki après avoir terminé ce README :
https://github.com/heartcombo/devise/wiki
Si vous découvrez un problème avec Devise, nous aimerions en être informés. Cependant, nous vous demandons de bien vouloir consulter ces directives avant de soumettre un rapport de bug :
https://github.com/heartcombo/devise/wiki/Bug-reports
Si vous avez découvert un bug lié à la sécurité, veuillez NE PAS utiliser le outil de suivi des problèmes GitHub. Envoyez un e-mail à [email protected].
Si vous avez des questions, des commentaires ou des préoccupations, veuillez utiliser StackOverflow au lieu de l'outil de suivi des problèmes GitHub :
http://stackoverflow.com/questions/tagged/devise
La liste de diffusion obsolète peut toujours être lue sur
https://groups.google.com/group/plataformatec-devise
Vous pouvez consulter la documentation Devise au format RDoc ici :
http://rubydoc.info/github/heartcombo/devise/main/frames
Si vous devez utiliser Devise avec des versions précédentes de Rails, vous pouvez toujours exécuter "gem server" à partir de la ligne de commande après avoir installé la gem pour accéder à l'ancienne documentation.
Il existe quelques exemples d'applications disponibles sur GitHub qui démontrent diverses fonctionnalités de Devise avec différentes versions de Rails. Vous pouvez les consulter ici :
https://github.com/heartcombo/devise/wiki/Example-Applications
Notre communauté a créé un certain nombre d'extensions qui ajoutent des fonctionnalités au-delà de ce qui est inclus avec Devise. Vous pouvez consulter une liste des extensions disponibles et ajouter la vôtre ici :
https://github.com/heartcombo/devise/wiki/Extensions
Nous espérons que vous envisagerez de contribuer à Devise. Veuillez lire ce bref aperçu pour obtenir des informations sur la façon de commencer :
https://github.com/heartcombo/devise/wiki/Contributing
Vous souhaiterez généralement écrire des tests pour vos modifications. Pour exécuter la suite de tests, accédez au répertoire de niveau supérieur de Devise et exécutez bundle install et bin/test . Devise fonctionne avec plusieurs versions de Ruby et Rails, ainsi qu'avec les ORM ActiveRecord et Mongoid, ce qui signifie que vous pouvez exécuter la suite de tests avec certains modificateurs : DEVISE_ORM et BUNDLE_GEMFILE .
Étant donné que Devise prend en charge à la fois Mongoid et ActiveRecord, nous nous appuyons sur cette variable pour exécuter du code spécifique pour chaque ORM. La valeur par défaut de DEVISE_ORM est active_record . Pour exécuter les tests pour Mongoid, vous pouvez passer mongoid :
DEVISE_ORM=mongoid bin/test
==> Devise.orm = :mongoid
Lors de l'exécution des tests pour Mongoid, vous devrez disposer d'un serveur MongoDB (version 2.0 ou plus récente) exécuté sur votre système.
Veuillez noter que le résultat de la commande affichera la valeur de la variable utilisée.
Nous pouvons utiliser cette variable pour indiquer au bundler quel Gemfile il doit utiliser (au lieu de celui du répertoire courant). Dans le répertoire gemfiles, nous en avons un pour chaque version de Rails que nous prenons en charge. Lorsque vous nous envoyez une pull request, il peut arriver que la suite de tests cesse d'utiliser certains d'entre eux. Si tel est le cas, vous pouvez simuler le même environnement en utilisant la variable BUNDLE_GEMFILE . Par exemple, si les tests ont échoué avec Ruby 3.0.0 et Rails 6.0, vous pouvez procéder comme suit :
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/testVous pouvez également combiner les deux si les tests ont échoué pour Mongoid :
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 DEVISE_ORM=mongoid bin/testDevise utilise Mini Test comme framework de test.
bin/testbin/test test/models/trackable_test.rbbin/test test/models/trackable_test.rb:16Si vous créez votre première application Rails, nous vous recommandons de ne pas utiliser Devise. Devise nécessite une bonne compréhension du framework Rails. Dans de tels cas, nous vous conseillons de démarrer un système d’authentification simple à partir de zéro. Voici quelques ressources qui devraient vous aider à démarrer :
Une fois que vous aurez solidifié votre compréhension de Rails et des mécanismes d’authentification, nous vous assurons qu’il sera très agréable de travailler avec Devise. ?
Devise 4.0 fonctionne avec Rails 6.0 et versions ultérieures. Courir:
bundle add deviseEnsuite, vous devez exécuter le générateur :
rails generate devise:install À ce stade, un certain nombre d'instructions apparaîtront dans la console. Parmi ces instructions, vous devrez configurer les options d'URL par défaut pour le courrier Devise dans chaque environnement. Voici une configuration possible pour config/environments/development.rb :
config . action_mailer . default_url_options = { host : 'localhost' , port : 3000 }Le générateur installera un initialiseur qui décrit TOUTES les options de configuration de Devise. Il est impératif que vous y jetiez un œil. Lorsque vous avez terminé, vous êtes prêt à ajouter Devise à n'importe lequel de vos modèles à l'aide du générateur.
Dans la commande suivante, vous remplacerez MODEL par le nom de classe utilisé pour les utilisateurs de l'application (il s'agit souvent User mais cela peut aussi être Admin ). Cela créera un modèle (s'il n'en existe pas) et le configurera avec les modules Devise par défaut. Le générateur configure également votre fichier config/routes.rb pour pointer vers le contrôleur Devise.
rails generate devise MODELEnsuite, vérifiez le MODÈLE pour toute option de configuration supplémentaire que vous pourriez souhaiter ajouter, telle que confirmable ou verrouillable. Si vous ajoutez une option, assurez-vous d'inspecter le fichier de migration (créé par le générateur si votre ORM les prend en charge) et de décommenter la section appropriée. Par exemple, si vous ajoutez l'option confirmable dans le modèle, vous devrez supprimer le commentaire de la section Confirmable dans la migration.
Ensuite, exécutez rails db:migrate
Vous devez redémarrer votre application après avoir modifié les options de configuration de Devise (cela inclut l'arrêt du ressort). Sinon, vous rencontrerez des erreurs étranges, par exemple, les utilisateurs ne pourront pas se connecter et les assistants d'acheminement ne seront pas définis.
Devise créera des assistants à utiliser dans vos contrôleurs et vues. Pour configurer un contrôleur avec authentification utilisateur, ajoutez simplement ceci before_action (en supposant que votre modèle de périphérique est « Utilisateur ») :
before_action :authenticate_user! Pour Rails 5, notez que protect_from_forgery n'est plus ajouté au début de la chaîne before_action , donc si vous avez défini authenticate_user avant protect_from_forgery , votre demande entraînera "Impossible de vérifier l'authenticité du jeton CSRF". Pour résoudre ce problème, modifiez l'ordre dans lequel vous les appelez ou utilisez protect_from_forgery prepend: true .
Si le modèle de votre appareil est autre que User, remplacez "_user" par "_yourmodel". La même logique s’applique aux instructions ci-dessous.
Pour vérifier si un utilisateur est connecté, utilisez l'assistant suivant :
user_signed_in?Pour l'utilisateur actuellement connecté, cette assistance est disponible :
current_userVous pouvez accéder à la session pour cette portée :
user_session Après avoir connecté un utilisateur, confirmé le compte ou mis à jour le mot de passe, Devise recherchera un chemin racine étendu vers lequel rediriger. Par exemple, lors de l'utilisation d'une ressource :user , le user_root_path sera utilisé s'il existe ; sinon, le root_path par défaut sera utilisé. Cela signifie que vous devez définir la racine dans vos routes :
root to : 'home#index' Vous pouvez également remplacer after_sign_in_path_for et after_sign_out_path_for pour personnaliser vos hooks de redirection.
Notez que si votre modèle Devise s'appelle Member au lieu de User , par exemple, alors les assistants disponibles sont :
before_action :authenticate_member!
member_signed_in?
current_member
member_sessionLa méthode Devise dans vos modèles accepte également certaines options pour configurer ses modules. Par exemple, vous pouvez choisir le coût de l’algorithme de hachage avec :
devise :database_authenticatable , :registerable , :confirmable , :recoverable , stretches : 13 Outre :stretches , vous pouvez définir :pepper , :encryptor , :confirm_within , :remember_for , :timeout_in , :unlock_in entre autres options. Pour plus de détails, consultez le fichier d'initialisation créé lorsque vous avez appelé le générateur « devise:install » décrit ci-dessus. Ce fichier se trouve généralement dans /config/initializers/devise.rb .
L'API Parameter Sanitizer a changé pour Devise 4
Pour les versions précédentes de Devise, voir https://github.com/heartcombo/devise/tree/3-stable#strong-parameters
Lorsque vous personnalisez vos propres vues, vous risquez d'ajouter de nouveaux attributs aux formulaires. Rails 4 a déplacé la désinfection des paramètres du modèle vers le contrôleur, ce qui a amené Devise à gérer également ce problème au niveau du contrôleur.
Il n'y a que trois actions dans Devise qui permettent de transmettre n'importe quel ensemble de paramètres au modèle, nécessitant donc une désinfection. Leurs noms et paramètres autorisés par défaut sont :
sign_in ( Devise::SessionsController#create ) - Autorise uniquement les clés d'authentification (comme email )sign_up ( Devise::RegistrationsController#create ) - Autorise les clés d'authentification ainsi que password et password_confirmationaccount_update ( Devise::RegistrationsController#update ) - Autorise les clés d'authentification plus password , password_confirmation et current_password Si vous souhaitez autoriser des paramètres supplémentaires (à la manière paresseuse™), vous pouvez le faire en utilisant une simple action préalable dans votre ApplicationController :
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 Ce qui précède fonctionne pour tous les champs supplémentaires où les paramètres sont de simples types scalaires. Si vous avez des attributs imbriqués (disons que vous utilisez accepts_nested_attributes_for ), vous devrez alors indiquer à Devise ces imbrications et ces types :
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
endDevise vous permet de modifier complètement les valeurs par défaut de Devise ou d'invoquer un comportement personnalisé en passant un bloc :
Pour autoriser des valeurs scalaires simples pour le nom d'utilisateur et l'e-mail, utilisez ceci
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_in ) do | user_params |
user_params . permit ( :username , :email )
end
endSi vous disposez de cases à cocher qui expriment les rôles qu'un utilisateur peut assumer lors de l'inscription, le navigateur enverra ces cases à cocher sélectionnées sous forme de tableau. Un tableau ne fait pas partie des scalaires autorisés par Strong Parameters, nous devons donc configurer Devise de la manière suivante :
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_up ) do | user_params |
user_params . permit ( { roles : [ ] } , :email , :password , :password_confirmation )
end
endPour la liste des scalaires autorisés et comment déclarer les clés autorisées dans les hachages et les tableaux imbriqués, voir
https://github.com/rails/strong_parameters#nested-parameters
Si vous disposez de plusieurs modèles Devise, vous souhaiterez peut-être configurer un désinfectant de paramètres différent par modèle. Dans ce cas, nous vous recommandons d'hériter de Devise::ParameterSanitizer et d'ajouter votre propre logique :
class User :: ParameterSanitizer < Devise :: ParameterSanitizer
def initialize ( * )
super
permit ( :sign_up , keys : [ :username , :email ] )
end
endEt puis configurez vos contrôleurs pour l'utiliser :
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 L'exemple ci-dessus remplace les paramètres autorisés pour l'utilisateur afin qu'ils soient à la fois :username et :email . La manière non paresseuse de configurer les paramètres consisterait à définir le filtre avant ci-dessus dans un contrôleur personnalisé. Nous détaillons comment configurer et personnaliser les contrôleurs dans certaines sections ci-dessous.
Nous avons créé Devise pour vous aider à développer rapidement une application utilisant l'authentification. Cependant, nous ne voulons pas vous gêner lorsque vous devez le personnaliser.
Puisque Devise est un moteur, toutes ses vues sont regroupées dans la gemme. Ces vues vous aideront à démarrer, mais après un certain temps, vous souhaiterez peut-être les modifier. Si tel est le cas, il vous suffit d'invoquer le générateur suivant, et il copiera toutes les vues dans votre application :
rails generate devise:views Si vous avez plusieurs modèles Devise dans votre application (tels que User et Admin ), vous remarquerez que Devise utilise les mêmes vues pour tous les modèles. Heureusement, Devise offre un moyen simple de personnaliser les vues. Tout ce que vous avez à faire est de définir config.scoped_views = true dans le fichier config/initializers/devise.rb .
Après cela, vous pourrez avoir des vues basées sur le rôle comme users/sessions/new et admins/sessions/new . Si aucune vue n'est trouvée dans la portée, Devise utilisera la vue par défaut dans devise/sessions/new . Vous pouvez également utiliser le générateur pour générer des vues étendues :
rails generate devise:views users Si vous souhaitez générer seulement quelques ensembles de vues, comme celles du module registerable et confirmable , vous pouvez transmettre une liste de vues au générateur avec l'option -v .
rails generate devise:views -v registrations confirmationsSi la personnalisation au niveau des vues ne suffit pas, vous pouvez personnaliser chaque contrôleur en suivant ces étapes :
Créez vos contrôleurs personnalisés à l'aide du générateur qui nécessite une portée :
rails generate devise:controllers [scope] Si vous spécifiez users comme étendue, les contrôleurs seront créés dans app/controllers/users/ . Et le contrôleur de sessions ressemblera à ceci :
class Users :: SessionsController < Devise :: SessionsController
# GET /resource/sign_in
# def new
# super
# end
...
end Utilisez l'option -c pour spécifier un ou plusieurs contrôleurs, par exemple : rails generate devise:controllers users -c sessions
Dites au routeur d'utiliser ce contrôleur :
devise_for :users , controllers : { sessions : 'users/sessions' } Recommandé mais pas obligatoire : copiez (ou déplacez) les vues de devise/sessions vers users/sessions . Rails continuera à utiliser les vues des devise/sessions en raison de l'héritage si vous sautez cette étape, mais le fait que les vues correspondent au(x) contrôleur(s) maintient la cohérence des choses.
Enfin, modifiez ou étendez les actions souhaitées du contrôleur.
Vous pouvez complètement remplacer une action du contrôleur :
class Users :: SessionsController < Devise :: SessionsController
def create
# custom sign-in code
end
endOu vous pouvez simplement y ajouter un nouveau comportement :
class Users :: SessionsController < Devise :: SessionsController
def create
super do | resource |
BackgroundWorker . trigger ( resource )
end
end
endCeci est utile pour déclencher des tâches en arrière-plan ou enregistrer des événements lors de certaines actions.
N'oubliez pas que Devise utilise des messages flash pour informer les utilisateurs si la connexion a réussi ou échoué. Devise s'attend à ce que votre application appelle flash[:notice] et flash[:alert] selon le cas. N'imprimez pas l'intégralité du hachage flash, imprimez uniquement des clés spécifiques. Dans certaines circonstances, Devise ajoute une clé :timedout au hachage flash, qui n'est pas destiné à l'affichage. Supprimez cette clé du hachage si vous avez l'intention d'imprimer l'intégralité du hachage.
Devise est également livré avec des itinéraires par défaut. Si vous avez besoin de les personnaliser, vous devriez probablement pouvoir le faire via la méthode devise_for. Il accepte plusieurs options comme :class_name, :path_prefix et ainsi de suite, y compris la possibilité de changer les noms de chemin pour I18n :
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' } Assurez-vous de consulter la documentation devise_for pour plus de détails.
Si vous avez besoin d'une personnalisation plus approfondie, par exemple pour autoriser également "/sign_in" en plus de "/users/sign_in", tout ce que vous avez à faire est de créer vos routes normalement et de les envelopper dans un bloc devise_scope dans le routeur :
devise_scope :user do
get 'sign_in' , to : 'devise/sessions#new'
end De cette façon, vous dites à Devise d'utiliser le scope :user lors de l'accès à "/sign_in". Remarquez que devise_scope est également alias as dans votre routeur.
Remarque : vous devrez toujours ajouter devise_for dans vos itinéraires afin d'utiliser des méthodes d'assistance telles que current_user .
devise_for :users , skip : :allDevise s'intègre à Hotwire/Turbo en traitant ces requêtes comme des requêtes de navigation et en configurant certaines réponses aux erreurs et aux redirections pour qu'elles correspondent au comportement attendu. Les nouvelles applications sont générées par défaut avec la configuration de réponse suivante, et les applications existantes peuvent s'inscrire en ajoutant la configuration à leurs initialiseurs Devise :
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 Important : ces réponses personnalisées nécessitent que la version de la gem responders soit 3.1.0 ou supérieure, assurez-vous de la mettre à jour si vous comptez utiliser cette configuration. Consultez ce guide de mise à niveau pour plus d'informations.
Remarque : la configuration des statuts ci-dessus pourrait devenir la configuration par défaut pour Devise dans une prochaine version.
Vous devrez peut-être apporter quelques autres modifications à votre application pour fonctionner avec Hotwire/Turbo, si vous migrez depuis rails-ujs :
data-confirm qui ajoute un modal de confirmation aux boutons/formulaires avant la soumission doit être remplacée par data-turbo-confirm , afin que Turbo les gère de manière appropriée.data-method qui définit la méthode de demande pour les soumissions de liens doit être remplacée par data-turbo-method . Cela n'est pas nécessaire pour button_to ou form s puisque Turbo peut les gérer. Si vous configurez Devise pour vous déconnecter via :delete et que vous utilisez des liens (au lieu de boutons enveloppés dans un formulaire) pour vous déconnecter avec l' method: :delete , ils devront être mis à jour comme décrit ci-dessus. (Devise ne fournit pas de liens/boutons de déconnexion dans ses vues partagées.)
Assurez-vous d'inspecter vos vues à la recherche de celles-ci et de les modifier en conséquence.
Devise utilise des messages flash avec I18n, en conjonction avec les touches flash :notice et :alert. Pour personnaliser votre application, vous pouvez configurer votre fichier de paramètres régionaux :
en :
devise :
sessions :
signed_in : ' Signed in successfully. 'Vous pouvez également créer des messages distincts en fonction de la ressource que vous avez configurée en utilisant le nom singulier donné dans les routes :
en :
devise :
sessions :
user :
signed_in : ' Welcome user, you are signed in. '
admin :
signed_in : ' Hello admin! 'Le logiciel de messagerie Devise utilise un modèle similaire pour créer des messages d'objet :
en :
devise :
mailer :
confirmation_instructions :
subject : ' Hello everybody! '
user_subject : ' Hello User! Please confirm your email '
reset_password_instructions :
subject : ' Reset instructions 'Jetez un œil à notre fichier de paramètres régionaux pour vérifier tous les messages disponibles. Vous pourriez également être intéressé par l’une des nombreuses traductions disponibles sur notre wiki :
https://github.com/heartcombo/devise/wiki/I18n
Attention : les contrôleurs Devise héritent d'ApplicationController. Si votre application utilise plusieurs paramètres régionaux, vous devez vous assurer de définir I18n.locale dans ApplicationController.
Devise comprend des assistants de test pour les tests de contrôleur et d'intégration. Pour les utiliser, vous devez inclure le module correspondant dans vos cas de test/spécifications.
Les tests de contrôleur nécessitent que vous incluiez Devise::Test::IntegrationHelpers dans votre scénario de test ou sa superclasse ActionController::TestCase parent. Pour les versions Rails antérieures à 5, incluez plutôt Devise::Test::ControllerHelpers , puisque la superclasse pour les tests de contrôleur a été modifiée en ActionDispatch::IntegrationTest (pour plus de détails, voir la section Tests d'intégration).
class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: IntegrationHelpers # Rails >= 5
end class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: ControllerHelpers # Rails < 5
end Si vous utilisez RSpec, vous pouvez placer les éléments suivants dans un fichier nommé spec/support/devise.rb ou dans votre spec/spec_helper.rb (ou spec/rails_helper.rb si vous utilisez rspec-rails ) :
RSpec . configure do | config |
config . include Devise :: Test :: ControllerHelpers , type : :controller
config . include Devise :: Test :: ControllerHelpers , type : :view
end Assurez-vous simplement que cette inclusion est faite après la directive require 'rspec/rails' .
Vous êtes maintenant prêt à utiliser les méthodes sign_in et sign_out sur vos tests de contrôleur :
sign_in @user
sign_in @user , scope : :adminSi vous testez des contrôleurs internes de Devise ou un contrôleur qui hérite de celui de Devise, vous devez indiquer à Devise quel mappage doit être utilisé avant une requête. Cela est nécessaire car Devise obtient ces informations du routeur, mais comme les tests du contrôleur ne transitent pas par le routeur, cela doit être indiqué explicitement. Par exemple, si vous testez la portée utilisateur, utilisez simplement :
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 Les aides aux tests d'intégration sont disponibles en incluant le module Devise::Test::IntegrationHelpers .
class PostsTests < ActionDispatch :: IntegrationTest
include Devise :: Test :: IntegrationHelpers
end Vous pouvez désormais utiliser les méthodes sign_in et sign_out suivantes dans vos tests d'intégration :
sign_in users ( :bob )
sign_in users ( :bob ) , scope : :admin
sign_out :user Les utilisateurs de RSpec peuvent inclure le module IntegrationHelpers dans leurs spécifications :feature .
RSpec . configure do | config |
config . include Devise :: Test :: IntegrationHelpers , type : :feature
end Contrairement aux tests de contrôleur, les tests d'intégration n'ont pas besoin de fournir la valeur env devise.mapping , car le mappage peut être déduit des routes exécutées dans vos tests.
Vous pouvez en savoir plus sur le test de vos contrôleurs Rails avec RSpec dans le wiki :
Devise est livré avec la prise en charge OmniAuth prête à l'emploi pour s'authentifier auprès d'autres fournisseurs. Pour l'utiliser, spécifiez simplement votre configuration OmniAuth dans config/initializers/devise.rb :
config . omniauth :github , 'APP_ID' , 'APP_SECRET' , scope : 'user,public_repo'Vous pouvez en savoir plus sur la prise en charge d'OmniAuth dans le wiki :
Devise vous permet de configurer autant de modèles Devise que vous le souhaitez. Si vous souhaitez disposer d'un modèle Administrateur avec uniquement des fonctionnalités d'authentification et de délai d'attente, en plus du modèle Utilisateur ci-dessus, exécutez simplement :
# 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_sessionAlternativement, vous pouvez simplement exécuter le générateur Devise.
Gardez à l’esprit que ces modèles auront des itinéraires complètement différents. Ils ne partagent pas et ne peuvent pas partager le même contrôleur pour la connexion, la déconnexion, etc. Si vous souhaitez que différents rôles partagent les mêmes actions, nous vous recommandons d'utiliser une approche basée sur les rôles, soit en fournissant une colonne de rôle, soit en utilisant une gem dédiée pour l'autorisation.
Si vous utilisez Active Job pour envoyer des messages Action Mailer en arrière-plan via un back-end de file d'attente, vous pouvez envoyer des e-mails Devise via votre file d'attente existante en remplaçant la méthode send_devise_notification dans votre modèle.
def send_devise_notification ( notification , * args )
devise_mailer . send ( notification , self , * args ) . deliver_later
endSi vous activez le module Récupérable, notez qu'un jeton de réinitialisation de mot de passe volé pourrait donner à un attaquant l'accès à votre application. Devise s'efforce de générer des jetons aléatoires et sécurisés et stocke uniquement les résumés de jetons dans la base de données, jamais en texte brut. Cependant, le comportement de journalisation par défaut dans Rails peut entraîner la fuite de jetons en texte brut dans les fichiers journaux :
deliver_later pour envoyer des e-mails de réinitialisation de mot de passe, les jetons de réinitialisation de mot de passe seront divulgués. Rails définit le niveau d'enregistreur de production sur INFO par défaut. Pensez à modifier le niveau de votre enregistreur de production sur WARN si vous souhaitez empêcher la fuite de jetons dans vos journaux. Dans config/environments/production.rb :
config . log_level = :warnDevise prend en charge ActiveRecord (par défaut) et Mongoid. Pour sélectionner un autre ORM, exigez-le simplement dans le fichier d'initialisation.
Rails 5+ dispose d'un mode API intégré qui optimise Rails pour une utilisation en tant qu'API (uniquement). Devise est quelque peu capable de gérer les applications construites dans ce mode sans modifications supplémentaires dans le sens où il ne doit pas déclencher d'exceptions, etc. Mais certains problèmes peuvent encore survenir lors development / testing , car nous ne connaissons pas encore toute l'étendue de cette compatibilité. (Pour plus d'informations, voir le numéro 4947)
Les applications API uniquement ne prennent pas en charge l'authentification basée sur le navigateur via les cookies, ce qui est la valeur par défaut de l'appareil. Pourtant, Devise peut toujours fournir une authentification prête à l'emploi dans ces cas-là grâce à la stratégie http_authenticatable , qui utilise HTTP Basic Auth et authentifie l'utilisateur à chaque requête. (Pour plus d'informations, consultez cet article wiki pour savoir comment : utiliser l'authentification HTTP de base.)
La valeur par défaut du périphérique pour l'authentification HTTP est désactivée. Elle devra donc être activée dans l'initialiseur du périphérique pour la stratégie de base de données :
config . http_authenticatable = [ :database ]Cette restriction ne vous empêche pas de mettre en œuvre des stratégies de gardien personnalisées, que ce soit dans votre application ou via des extensions basées sur des gemmes pour Devise. Une stratégie d'authentification courante pour les API est l'authentification basée sur des jetons. Pour plus d'informations sur l'extension de Devise pour prendre en charge ce type d'authentification et d'autres, consultez l'article wiki Exemples et alternatives d'authentification par jeton simple ou cet article de blog sur les méthodes d'authentification personnalisées avec Devise.
Le mode API modifie l'ordre de la pile middleware, ce qui peut entraîner des problèmes pour Devise::Test::IntegrationHelpers . Ce problème apparaît généralement comme une undefined method `[]=' for nil:NilClass lors de l'utilisation d'assistants de test d'intégration, tels que #sign_in . La solution consiste simplement à réorganiser les middlewares en ajoutant ce qui suit à test.rb :
Rails . application
