devise
v4.9.4
Devise es una solución de autenticación flexible para Rails basada en Warden. Él:
Está compuesto por 10 módulos:
Devise Wiki tiene mucha información adicional sobre Devise, incluidos muchos artículos prácticos y respuestas a las preguntas más frecuentes. Navegue por la Wiki después de terminar este archivo README:
https://github.com/heartcombo/devise/wiki
Si descubre un problema con Devise, nos gustaría informarnos. Sin embargo, le pedimos que revise estas pautas antes de enviar un informe de error:
https://github.com/heartcombo/devise/wiki/Bug-reports
Si ha descubierto un error relacionado con la seguridad, NO utilice el rastreador de problemas de GitHub. Envíe un correo electrónico a [email protected].
Si tiene alguna pregunta, comentario o inquietud, utilice StackOverflow en lugar del rastreador de problemas de GitHub:
http://stackoverflow.com/questions/tagged/devise
La lista de correo obsoleta todavía se puede leer en
https://groups.google.com/group/plataformatec-devise
Puede ver la documentación de Devise en formato RDoc aquí:
http://rubydoc.info/github/heartcombo/devise/main/frames
Si necesita utilizar Devise con versiones anteriores de Rails, siempre puede ejecutar el "servidor de gemas" desde la línea de comando después de instalar la gema para acceder a la documentación anterior.
Hay algunas aplicaciones de ejemplo disponibles en GitHub que demuestran varias características de Devise con diferentes versiones de Rails. Puedes verlos aquí:
https://github.com/heartcombo/devise/wiki/Example-Applications
Nuestra comunidad ha creado una serie de extensiones que agregan funcionalidad más allá de lo que se incluye con Devise. Puede ver una lista de extensiones disponibles y agregar la suya propia aquí:
https://github.com/heartcombo/devise/wiki/Extensions
Esperamos que considere contribuir a Devise. Lea esta breve descripción general para obtener información sobre cómo comenzar:
https://github.com/heartcombo/devise/wiki/Contributing
Generalmente querrás escribir pruebas para tus cambios. Para ejecutar el conjunto de pruebas, vaya al directorio de nivel superior de Devise y ejecute bundle install y bin/test . Devise funciona con múltiples versiones de Ruby y Rails, y ORM ActiveRecord y Mongoid, lo que significa que puede ejecutar el conjunto de pruebas con algunos modificadores: DEVISE_ORM y BUNDLE_GEMFILE .
Dado que Devise admite tanto Mongoid como ActiveRecord, confiamos en esta variable para ejecutar código específico para cada ORM. El valor predeterminado de DEVISE_ORM es active_record . Para ejecutar las pruebas de Mongoid, puede pasar mongoid :
DEVISE_ORM=mongoid bin/test
==> Devise.orm = :mongoid
Al ejecutar las pruebas de Mongoid, necesitará tener un servidor MongoDB (versión 2.0 o posterior) ejecutándose en su sistema.
Tenga en cuenta que la salida del comando mostrará el valor de la variable que se está utilizando.
Podemos usar esta variable para indicarle al paquete qué Gemfile debe usar (en lugar del que está en el directorio actual). Dentro del directorio gemfiles, tenemos uno para cada versión de Rails que admitimos. Cuando nos envía una solicitud de extracción, puede suceder que el conjunto de pruebas falle al utilizar algunos de ellos. Si ese es el caso, puedes simular el mismo entorno usando la variable BUNDLE_GEMFILE . Por ejemplo, si las pruebas fallaron al usar Ruby 3.0.0 y Rails 6.0, puedes hacer lo siguiente:
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/testTambién puedes combinar ambos si las pruebas fallaron para Mongoid:
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 DEVISE_ORM=mongoid bin/testDevise utiliza Mini Test como marco de prueba.
bin/testbin/test test/models/trackable_test.rbbin/test test/models/trackable_test.rb:16Si está creando su primera aplicación Rails, le recomendamos que no utilice Devise. Devise requiere una buena comprensión del marco Rails. En tales casos, le recomendamos que inicie un sistema de autenticación sencillo desde cero. Aquí hay algunos recursos que deberían ayudarlo a comenzar:
Una vez que haya solidificado su comprensión de Rails y los mecanismos de autenticación, le aseguramos que será muy agradable trabajar con Devise. ?
Devise 4.0 funciona con Rails 6.0 en adelante. Correr:
bundle add deviseA continuación, necesitas ejecutar el generador:
rails generate devise:install En este punto, aparecerán una serie de instrucciones en la consola. Entre estas instrucciones, deberá configurar las opciones de URL predeterminadas para el correo de Devise en cada entorno. Aquí hay una posible configuración para config/environments/development.rb :
config . action_mailer . default_url_options = { host : 'localhost' , port : 3000 }El generador instalará un inicializador que describe TODAS las opciones de configuración de Devise. Es imprescindible que le eches un vistazo. Cuando haya terminado, estará listo para agregar Devise a cualquiera de sus modelos usando el generador.
En el siguiente comando, reemplazará MODEL con el nombre de clase utilizado para los usuarios de la aplicación (frecuentemente es User pero también podría ser Admin ). Esto creará un modelo (si no existe ninguno) y lo configurará con los módulos predeterminados de Devise. El generador también configura su archivo config/routes.rb para que apunte al controlador Devise.
rails generate devise MODELA continuación, verifique el MODELO para ver las opciones de configuración adicionales que desee agregar, como confirmables o bloqueables. Si agrega una opción, asegúrese de inspeccionar el archivo de migración (creado por el generador si su ORM lo admite) y descomente la sección correspondiente. Por ejemplo, si agrega la opción confirmable en el modelo, deberá descomentar la sección Confirmable en la migración.
Luego ejecute rails db:migrate
Debe reiniciar su aplicación después de cambiar las opciones de configuración de Devise (esto incluye detener Spring). De lo contrario, se encontrará con errores extraños, por ejemplo, que los usuarios no puedan iniciar sesión y que los asistentes de ruta no estén definidos.
Devise creará algunos ayudantes para usar dentro de sus controladores y vistas. Para configurar un controlador con autenticación de usuario, simplemente agregue esto before_action (suponiendo que su modelo de dispositivo sea 'Usuario'):
before_action :authenticate_user! Para Rails 5, tenga en cuenta que protect_from_forgery ya no se antepone a la cadena before_action , por lo que si configuró authenticate_user antes de protect_from_forgery , su solicitud dará como resultado "No se puede verificar la autenticidad del token CSRF". Para resolver esto, cambie el orden en el que los llama o use protect_from_forgery prepend: true .
Si el modelo de su dispositivo no es Usuario, reemplace "_user" con "_yourmodel". La misma lógica se aplica a las instrucciones siguientes.
Para verificar si un usuario ha iniciado sesión, utilice la siguiente ayuda:
user_signed_in?Para el usuario que ha iniciado sesión actualmente, esta ayuda está disponible:
current_userPuedes acceder a la sesión para este ámbito:
user_session Después de iniciar sesión como usuario, confirmar la cuenta o actualizar la contraseña, Devise buscará una ruta raíz específica a la que redirigir. Por ejemplo, cuando se utiliza un recurso :user , se utilizará user_root_path si existe; de lo contrario, se utilizará la root_path predeterminada. Esto significa que necesitas configurar la raíz dentro de tus rutas:
root to : 'home#index' También puede anular after_sign_in_path_for y after_sign_out_path_for para personalizar sus enlaces de redireccionamiento.
Tenga en cuenta que si su modelo de Devise se llama Member en lugar de User , por ejemplo, los ayudantes disponibles son:
before_action :authenticate_member!
member_signed_in?
current_member
member_sessionEl método Devise en tus modelos también acepta algunas opciones para configurar sus módulos. Por ejemplo, puedes elegir el coste del algoritmo hash con:
devise :database_authenticatable , :registerable , :confirmable , :recoverable , stretches : 13 Además de :stretches , puedes definir :pepper , :encryptor , :confirm_within , :remember_for , :timeout_in , :unlock_in entre otras opciones. Para obtener más detalles, consulte el archivo inicializador que se creó cuando invocó el generador "devise:install" descrito anteriormente. Este archivo normalmente se encuentra en /config/initializers/devise.rb .
La API de Parameter Sanitizer ha cambiado para Devise 4
Para versiones anteriores de Devise, consulte https://github.com/heartcombo/devise/tree/3-stable#strong-parameters
Cuando personaliza sus propias vistas, puede terminar agregando nuevos atributos a los formularios. Rails 4 movió la desinfección de parámetros del modelo al controlador, lo que provocó que Devise también manejara esta preocupación en el controlador.
Solo hay tres acciones en Devise que permiten que cualquier conjunto de parámetros se transmita al modelo, por lo que requieren desinfección. Sus nombres y parámetros permitidos por defecto son:
sign_in ( Devise::SessionsController#create ): permite solo las claves de autenticación (como email )sign_up ( Devise::RegistrationsController#create ): permite claves de autenticación más password y password_confirmationaccount_update ( Devise::RegistrationsController#update ): permite claves de autenticación más password , password_confirmation y current_password En caso de que desee permitir parámetros adicionales (lazy way™), puede hacerlo usando una simple acción previa en su 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 Lo anterior funciona para cualquier campo adicional donde los parámetros sean tipos escalares simples. Si tiene atributos anidados (digamos que está usando accepts_nested_attributes_for ), deberá informarle a Devise sobre esos anidamientos y tipos:
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 le permite cambiar completamente los valores predeterminados de Devise o invocar un comportamiento personalizado pasando un bloque:
Para permitir valores escalares simples para el nombre de usuario y el correo electrónico, utilice esto
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_in ) do | user_params |
user_params . permit ( :username , :email )
end
endSi tiene algunas casillas de verificación que expresan los roles que un usuario puede asumir al registrarse, el navegador enviará esas casillas seleccionadas como una matriz. Una matriz no es uno de los escalares permitidos por Strong Parameters, por lo que debemos configurar Devise de la siguiente manera:
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_up ) do | user_params |
user_params . permit ( { roles : [ ] } , :email , :password , :password_confirmation )
end
endPara obtener la lista de escalares permitidos y cómo declarar claves permitidas en matrices y hashes anidados, consulte
https://github.com/rails/strong_parameters#nested-parameters
Si tiene varios modelos de Devise, es posible que desee configurar un desinfectante de parámetros diferente para cada modelo. En este caso, recomendamos heredar de Devise::ParameterSanitizer y agregar su propia lógica:
class User :: ParameterSanitizer < Devise :: ParameterSanitizer
def initialize ( * )
super
permit ( :sign_up , keys : [ :username , :email ] )
end
endY luego configure sus controladores para usarlo:
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 El ejemplo anterior anula los parámetros permitidos para que el usuario sea tanto :username como :email . La forma más sencilla de configurar los parámetros sería definiendo el filtro anterior anterior en un controlador personalizado. Detallamos cómo configurar y personalizar controladores en algunas secciones a continuación.
Creamos Devise para ayudarlo a desarrollar rápidamente una aplicación que utilice autenticación. Sin embargo, no queremos interponernos en su camino cuando necesite personalizarlo.
Dado que Devise es un motor, todas sus vistas están empaquetadas dentro de la gema. Estas vistas le ayudarán a empezar, pero después de un tiempo es posible que desee cambiarlas. Si este es el caso, sólo necesita invocar el siguiente generador y copiará todas las vistas a su aplicación:
rails generate devise:views Si tiene más de un modelo de Devise en su aplicación (como User y Admin ), notará que Devise usa las mismas vistas para todos los modelos. Afortunadamente, Devise ofrece una manera sencilla de personalizar las vistas. Todo lo que necesitas hacer es configurar config.scoped_views = true dentro del archivo config/initializers/devise.rb .
Después de hacerlo, podrá tener vistas basadas en el rol, como users/sessions/new y admins/sessions/new . Si no se encuentra ninguna vista dentro del alcance, Devise utilizará la vista predeterminada en devise/sessions/new . También puede utilizar el generador para generar vistas con alcance:
rails generate devise:views users Si desea generar solo unos pocos conjuntos de vistas, como las del módulo registerable y confirmable , puede pasar una lista de vistas al generador con el indicador -v .
rails generate devise:views -v registrations confirmationsSi la personalización a nivel de vistas no es suficiente, puedes personalizar cada controlador siguiendo estos pasos:
Cree sus controladores personalizados utilizando el generador que requiere un alcance:
rails generate devise:controllers [scope] Si especifica users como alcance, los controladores se crearán en app/controllers/users/ . Y el controlador de sesiones se verá así:
class Users :: SessionsController < Devise :: SessionsController
# GET /resource/sign_in
# def new
# super
# end
...
end Utilice el indicador -c para especificar uno o más controladores, por ejemplo: rails generate devise:controllers users -c sessions
Dígale al enrutador que use este controlador:
devise_for :users , controllers : { sessions : 'users/sessions' } Recomendado pero no obligatorio: copie (o mueva) las vistas de devise/sessions a users/sessions . Rails continuará usando las vistas de devise/sessions debido a la herencia si omite este paso, pero tener las vistas que coincidan con los controladores mantiene la coherencia.
Finalmente, cambie o amplíe las acciones del controlador deseadas.
Puedes anular completamente una acción del controlador:
class Users :: SessionsController < Devise :: SessionsController
def create
# custom sign-in code
end
endO simplemente puede agregarle un nuevo comportamiento:
class Users :: SessionsController < Devise :: SessionsController
def create
super do | resource |
BackgroundWorker . trigger ( resource )
end
end
endEsto es útil para activar trabajos en segundo plano o registrar eventos durante ciertas acciones.
Recuerde que Devise utiliza mensajes flash para informar a los usuarios si el inicio de sesión se realizó correctamente o no. Devise espera que su aplicación llame a flash[:notice] y flash[:alert] según corresponda. No imprima el hash flash completo, imprima solo claves específicas. En algunas circunstancias, Devise agrega una clave :timedout al hash flash, que no está diseñada para mostrarse. Elimine esta clave del hash si desea imprimir el hash completo.
Devise también se envía con rutas predeterminadas. Si necesita personalizarlos, probablemente debería poder hacerlo mediante el método devise_for. Acepta varias opciones como :class_name, :path_prefix y demás, incluida la posibilidad de cambiar los nombres de ruta para 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' } Asegúrese de consultar la documentación devise_for para obtener más detalles.
Si necesita una personalización más profunda, por ejemplo, permitir también "/sign_in" además de "/users/sign_in", todo lo que necesita hacer es crear sus rutas normalmente y envolverlas en un bloque devise_scope en el enrutador:
devise_scope :user do
get 'sign_in' , to : 'devise/sessions#new'
end De esta manera, le indica a Devise que use el alcance :user cuando se accede a "/sign_in". Tenga en cuenta devise_scope también tiene un alias as en su enrutador.
Tenga en cuenta: aún necesitará agregar devise_for en sus rutas para poder utilizar métodos auxiliares como current_user .
devise_for :users , skip : :allDevise se integra con Hotwire/Turbo al tratar dichas solicitudes como de navegación y configurar ciertas respuestas para errores y redireccionamientos para que coincidan con el comportamiento esperado. Las nuevas aplicaciones se generan con la siguiente configuración de respuesta de forma predeterminada, y las aplicaciones existentes pueden optar por agregar la configuración a sus inicializadores de 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 Importante : estas respuestas personalizadas requieren que la versión de la gema responders sea 3.1.0 o superior; asegúrese de actualizarla si va a utilizar esta configuración. Consulte esta guía de actualización para obtener más información.
Nota : la configuración de estados anterior puede convertirse en la predeterminada para Devise en una versión futura.
Hay un par de cambios más que quizás debas realizar en tu aplicación para que funcione con Hotwire/Turbo, si estás migrando desde Rails-ujs:
data-confirm que agrega un modal de confirmación a los botones/formularios antes del envío debe cambiar a data-turbo-confirm , para que Turbo los maneje adecuadamente.data-method que establece el método de solicitud para el envío de enlaces debe cambiar a data-turbo-method . Esto no es necesario para button_to o form s ya que Turbo puede manejarlos. Si está configurando Devise para cerrar sesión a través de :delete y está utilizando enlaces (en lugar de botones incluidos en un formulario) para cerrar sesión con la opción method: :delete , deberán actualizarse como se describe anteriormente. (Devise no proporciona enlaces/botones de cierre de sesión en sus vistas compartidas).
Asegúrese de inspeccionar sus puntos de vista en busca de ellos y cámbielos apropiadamente.
Devise utiliza mensajes flash con I18n, junto con las teclas flash :aviso y :alerta. Para personalizar su aplicación, puede configurar su archivo local:
en :
devise :
sessions :
signed_in : ' Signed in successfully. 'También puedes crear mensajes distintos según el recurso que hayas configurado usando el nombre singular dado en las rutas:
en :
devise :
sessions :
user :
signed_in : ' Welcome user, you are signed in. '
admin :
signed_in : ' Hello admin! 'El anuncio publicitario de Devise utiliza un patrón similar para crear mensajes de asunto:
en :
devise :
mailer :
confirmation_instructions :
subject : ' Hello everybody! '
user_subject : ' Hello User! Please confirm your email '
reset_password_instructions :
subject : ' Reset instructions 'Eche un vistazo a nuestro archivo local para comprobar todos los mensajes disponibles. También te puede interesar una de las muchas traducciones que están disponibles en nuestra wiki:
https://github.com/heartcombo/devise/wiki/I18n
Precaución: Los controladores Devise heredan de ApplicationController. Si su aplicación utiliza varias configuraciones regionales, debe asegurarse de configurar I18n.locale en ApplicationController.
Devise incluye algunos ayudantes de prueba para pruebas de integración y de controlador. Para usarlos, debe incluir el módulo respectivo en sus casos/especificaciones de prueba.
Las pruebas de controlador requieren que incluya Devise::Test::IntegrationHelpers en su caso de prueba o su superclase principal ActionController::TestCase . Para las versiones de Rails anteriores a la 5, incluya Devise::Test::ControllerHelpers en su lugar, ya que la superclase para las pruebas del controlador se cambió a ActionDispatch::IntegrationTest (para obtener más detalles, consulte la sección Pruebas de integración).
class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: IntegrationHelpers # Rails >= 5
end class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: ControllerHelpers # Rails < 5
end Si está utilizando RSpec, puede colocar lo siguiente dentro de un archivo llamado spec/support/devise.rb o en su spec/spec_helper.rb (o spec/rails_helper.rb si está utilizando rspec-rails ):
RSpec . configure do | config |
config . include Devise :: Test :: ControllerHelpers , type : :controller
config . include Devise :: Test :: ControllerHelpers , type : :view
end Solo asegúrese de que esta inclusión se realice después de la directiva require 'rspec/rails' .
Ahora está listo para usar los métodos sign_in y sign_out en las pruebas de su controlador:
sign_in @user
sign_in @user , scope : :adminSi está probando controladores internos de Devise o un controlador que hereda de los de Devise, debe indicarle a Devise qué asignación debe usarse antes de una solicitud. Esto es necesario porque Devise obtiene esta información del enrutador, pero como las pruebas del controlador no pasan por el enrutador, es necesario indicarlo explícitamente. Por ejemplo, si está probando el alcance del usuario, simplemente use:
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 Los ayudantes de prueba de integración están disponibles al incluir el módulo Devise::Test::IntegrationHelpers .
class PostsTests < ActionDispatch :: IntegrationTest
include Devise :: Test :: IntegrationHelpers
end Ahora puede utilizar los siguientes métodos sign_in y sign_out en sus pruebas de integración:
sign_in users ( :bob )
sign_in users ( :bob ) , scope : :admin
sign_out :user Los usuarios de RSpec pueden incluir el módulo IntegrationHelpers en sus especificaciones :feature .
RSpec . configure do | config |
config . include Devise :: Test :: IntegrationHelpers , type : :feature
end A diferencia de las pruebas de controlador, las pruebas de integración no necesitan proporcionar el valor env devise.mapping , ya que la asignación se puede inferir a partir de las rutas que se ejecutan en las pruebas.
Puede leer más sobre cómo probar sus controladores Rails con RSpec en la wiki:
Devise viene con soporte OmniAuth listo para usar para autenticarse con otros proveedores. Para usarlo, simplemente especifique su configuración de OmniAuth en config/initializers/devise.rb :
config . omniauth :github , 'APP_ID' , 'APP_SECRET' , scope : 'user,public_repo'Puede leer más sobre la compatibilidad con OmniAuth en la wiki:
Devise le permite configurar tantos modelos de Devise como desee. Si desea tener un modelo de Administrador con solo funciones de autenticación y tiempo de espera, además del modelo de Usuario anterior, simplemente ejecute:
# 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_sessionAlternativamente, puede simplemente ejecutar el generador Devise.
Tenga en cuenta que esos modelos tendrán rutas completamente diferentes. No comparten ni pueden compartir el mismo controlador para iniciar sesión, cerrar sesión, etc. En caso de que desee que diferentes roles compartan las mismas acciones, le recomendamos que utilice un enfoque basado en roles, ya sea proporcionando una columna de roles o utilizando una gema dedicada para la autorización.
Si está utilizando Active Job para entregar mensajes de Action Mailer en segundo plano a través de un servidor de cola, puede enviar correos electrónicos de Devise a través de su cola existente anulando el método send_devise_notification en su modelo.
def send_devise_notification ( notification , * args )
devise_mailer . send ( notification , self , * args ) . deliver_later
endSi habilita el módulo Recuperable, tenga en cuenta que un token de restablecimiento de contraseña robado podría darle a un atacante acceso a su aplicación. Devise se esfuerza por generar tokens aleatorios y seguros, y almacena solo resúmenes de tokens en la base de datos, nunca texto sin formato. Sin embargo, el comportamiento de registro predeterminado en Rails puede hacer que los tokens de texto sin formato se filtren en los archivos de registro:
deliver_later para enviar correos electrónicos de restablecimiento de contraseña, se filtrarán tokens de restablecimiento de contraseña. Rails establece el nivel del registrador de producción en INFO de forma predeterminada. Considere cambiar el nivel de su registrador de producción a WARN si desea evitar que se filtren tokens en sus registros. En config/environments/production.rb :
config . log_level = :warnDevise admite ActiveRecord (predeterminado) y Mongoid. Para seleccionar otro ORM, simplemente solicítelo en el archivo inicializador.
Rails 5+ tiene un modo API incorporado que optimiza Rails para su uso como API (solamente). Devise es algo capaz de manejar aplicaciones que se construyen en este modo sin modificaciones adicionales en el sentido de que no debería generar excepciones y similares. Pero aún pueden surgir algunos problemas durante development / testing , ya que todavía no conocemos el alcance total de esta compatibilidad. (Para obtener más información, consulte el número 4947)
Las aplicaciones solo API no admiten la autenticación basada en navegador a través de cookies, que es la opción predeterminada del dispositivo. Sin embargo, Devise aún puede proporcionar autenticación lista para usar en esos casos con la estrategia http_authenticatable , que utiliza autenticación básica HTTP y autentica al usuario en cada solicitud. (Para obtener más información, consulte este artículo wiki sobre Cómo: utilizar la autenticación básica HTTP)
El valor predeterminado del diseño para la autenticación HTTP está deshabilitado, por lo que deberá habilitarse en el inicializador del diseño para la estrategia de la base de datos:
config . http_authenticatable = [ :database ]Esta restricción no le impide implementar estrategias de guardián personalizadas, ya sea en su aplicación o mediante extensiones basadas en gemas para devise. Una estrategia de autenticación común para las API es la autenticación basada en tokens. Para obtener más información sobre cómo ampliar Devise para admitir este tipo de autenticación y otros, consulte el artículo wiki sobre ejemplos y alternativas de autenticación de token simple o esta publicación de blog sobre métodos de autenticación personalizados con Devise.
El modo API cambia el orden de la pila de middleware y esto puede causar problemas a Devise::Test::IntegrationHelpers . Este problema generalmente surge como un undefined method `[]=' for nil:NilClass cuando se utilizan ayudas de prueba de integración, como #sign_in . La solución es simplemente reordenar los middlewares agregando lo siguiente a test.rb:
Rails . application
