devise
v4.9.4
Devise é uma solução de autenticação flexível para Rails baseada em Warden. Isto:
É composto por 10 módulos:
O Devise Wiki tem muitas informações adicionais sobre o Devise, incluindo muitos artigos "como fazer" e respostas às perguntas mais frequentes. Por favor, navegue no Wiki depois de terminar este README:
https://github.com/heartcombo/devise/wiki
Se você descobrir um problema com o Devise, gostaríamos de saber. No entanto, pedimos que você revise estas diretrizes antes de enviar um relatório de bug:
https://github.com/heartcombo/devise/wiki/Bug-reports
Se você descobriu um bug relacionado à segurança, NÃO use o rastreador de problemas do GitHub. Envie um e-mail para [email protected].
Se você tiver alguma dúvida, comentário ou preocupação, use StackOverflow em vez do rastreador de problemas do GitHub:
http://stackoverflow.com/questions/tagged/devise
A lista de discussão obsoleta ainda pode ser lida
https://groups.google.com/group/plataformatec-devise
Você pode visualizar a documentação do Devise em formato RDoc aqui:
http://rubydoc.info/github/heartcombo/devise/main/frames
Se você precisar usar o Devise com versões anteriores do Rails, você sempre pode executar "gem server" na linha de comando após instalar a gem para acessar a documentação antiga.
Existem alguns exemplos de aplicativos disponíveis no GitHub que demonstram vários recursos do Devise com diferentes versões do Rails. Você pode visualizá-los aqui:
https://github.com/heartcombo/devise/wiki/Example-Applications
Nossa comunidade criou uma série de extensões que adicionam funcionalidades além do que está incluído no Devise. Você pode ver uma lista de extensões disponíveis e adicionar a sua própria aqui:
https://github.com/heartcombo/devise/wiki/Extensions
Esperamos que você considere contribuir para o Devise. Leia esta breve visão geral para obter algumas informações sobre como começar:
https://github.com/heartcombo/devise/wiki/Contributing
Geralmente você desejará escrever testes para suas alterações. Para executar o conjunto de testes, acesse o diretório de nível superior do Devise e execute bundle install e bin/test . O Devise funciona com várias versões de Ruby e Rails e ORMs ActiveRecord e Mongoid, o que significa que você pode executar o conjunto de testes com alguns modificadores: DEVISE_ORM e BUNDLE_GEMFILE .
Como o Devise suporta Mongoid e ActiveRecord, contamos com esta variável para executar código específico para cada ORM. O valor padrão de DEVISE_ORM é active_record . Para executar os testes do Mongoid, você pode passar mongoid :
DEVISE_ORM=mongoid bin/test
==> Devise.orm = :mongoid
Ao executar os testes para o Mongoid, você precisará ter um servidor MongoDB (versão 2.0 ou mais recente) em execução no seu sistema.
Observe que a saída do comando mostrará o valor da variável que está sendo usada.
Podemos usar esta variável para informar ao bundler qual Gemfile ele deve usar (em vez daquele no diretório atual). Dentro do diretório gemfiles, temos um para cada versão do Rails que suportamos. Quando você nos envia uma solicitação pull, pode acontecer que o conjunto de testes quebre usando alguns deles. Se for esse o caso, você pode simular o mesmo ambiente usando a variável BUNDLE_GEMFILE . Por exemplo, se os testes falharam usando Ruby 3.0.0 e Rails 6.0, você pode fazer o seguinte:
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/testVocê também pode combinar os dois se os testes falharem no Mongoid:
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 DEVISE_ORM=mongoid bin/testDevise usa Mini Test como estrutura de teste.
bin/testbin/test test/models/trackable_test.rbbin/test test/models/trackable_test.rb:16Se você estiver construindo sua primeira aplicação Rails, recomendamos não usar o Devise. Devise requer um bom entendimento do Rails Framework. Nesses casos, aconselhamos iniciar um sistema de autenticação simples do zero. Aqui estão alguns recursos que devem ajudá-lo a começar:
Depois de solidificar sua compreensão do Rails e dos mecanismos de autenticação, garantimos que será muito agradável trabalhar com o Devise. ?
O Devise 4.0 funciona com Rails 6.0 em diante. Correr:
bundle add deviseEm seguida, você precisa iniciar o gerador:
rails generate devise:install Neste ponto, várias instruções aparecerão no console. Entre essas instruções, você precisará configurar as opções de URL padrão para o mailer do Devise em cada ambiente. Aqui está uma configuração possível para config/environments/development.rb :
config . action_mailer . default_url_options = { host : 'localhost' , port : 3000 }O gerador instalará um inicializador que descreve TODAS as opções de configuração do Devise. É imperativo que você dê uma olhada nisso. Quando terminar, você estará pronto para adicionar o Devise a qualquer um dos seus modelos usando o gerador.
No comando a seguir você substituirá MODEL pelo nome da classe usada para os usuários do aplicativo (frequentemente é User , mas também pode ser Admin ). Isso criará um modelo (se não existir) e o configurará com os módulos padrão do Devise. O gerador também configura seu arquivo config/routes.rb para apontar para o controlador Devise.
rails generate devise MODELEm seguida, verifique o MODELO para quaisquer opções de configuração adicionais que você queira adicionar, como confirmável ou bloqueável. Se você adicionar uma opção, certifique-se de inspecionar o arquivo de migração (criado pelo gerador se o seu ORM suportar) e descomente a seção apropriada. Por exemplo, se você adicionar a opção confirmável no modelo, precisará descomentar a seção Confirmável na migração.
Em seguida, execute rails db:migrate
Você deve reiniciar seu aplicativo após alterar as opções de configuração do Devise (isso inclui parar o spring). Caso contrário, você encontrará erros estranhos, por exemplo, os usuários não conseguem fazer login e os auxiliares de rota são indefinidos.
O Devise criará alguns ajudantes para usar dentro de seus controladores e visualizações. Para configurar um controlador com autenticação de usuário, basta adicionar este before_action (assumindo que seu modelo de dispositivo seja 'User'):
before_action :authenticate_user! Para Rails 5, observe que protect_from_forgery não está mais anexado à cadeia before_action , portanto, se você definiu authenticate_user antes de protect_from_forgery , sua solicitação resultará em "Não é possível verificar a autenticidade do token CSRF". Para resolver isso, altere a ordem em que você os chama ou use protect_from_forgery prepend: true .
Se o seu modelo de dispositivo for diferente de User, substitua "_user" por "_yourmodel". A mesma lógica se aplica às instruções abaixo.
Para verificar se um usuário está conectado, use o seguinte auxiliar:
user_signed_in?Para o usuário conectado atualmente, este auxiliar está disponível:
current_userVocê pode acessar a sessão para este escopo:
user_session Depois de fazer login de um usuário, confirmar a conta ou atualizar a senha, o Devise procurará um caminho raiz com escopo para redirecionar. Por exemplo, ao usar um recurso :user , o user_root_path será usado se existir; caso contrário, o root_path padrão será usado. Isso significa que você precisa definir a raiz dentro de suas rotas:
root to : 'home#index' Você também pode substituir after_sign_in_path_for e after_sign_out_path_for para personalizar seus ganchos de redirecionamento.
Observe que se o seu modelo Devise for chamado Member em vez de User , por exemplo, então os auxiliares disponíveis são:
before_action :authenticate_member!
member_signed_in?
current_member
member_sessionO método Devise em seus modelos também aceita algumas opções para configurar seus módulos. Por exemplo, você pode escolher o custo do algoritmo de hash com:
devise :database_authenticatable , :registerable , :confirmable , :recoverable , stretches : 13 Além de :stretches , você pode definir :pepper , :encryptor , :confirm_within , :remember_for , :timeout_in , :unlock_in entre outras opções. Para obter mais detalhes, consulte o arquivo inicializador que foi criado quando você invocou o gerador "devise:install" descrito acima. Este arquivo geralmente está localizado em /config/initializers/devise.rb .
A API Parameter Sanitizer foi alterada para o Devise 4
Para versões anteriores do Devise, consulte https://github.com/heartcombo/devise/tree/3-stable#strong-parameters
Ao personalizar suas próprias visualizações, você pode acabar adicionando novos atributos aos formulários. O Rails 4 moveu a sanitização de parâmetros do modelo para o controlador, fazendo com que o Devise também cuidasse dessa preocupação no controlador.
Existem apenas três ações no Devise que permitem que qualquer conjunto de parâmetros seja transmitido ao modelo, exigindo, portanto, higienização. Seus nomes e parâmetros padrão permitidos são:
sign_in ( Devise::SessionsController#create ) - Permite apenas as chaves de autenticação (como email )sign_up ( Devise::RegistrationsController#create ) - Permite chaves de autenticação mais password e password_confirmationaccount_update ( Devise::RegistrationsController#update ) - Permite chaves de autenticação mais password , password_confirmation e current_password Caso você queira permitir parâmetros adicionais (the Lazy Way™), você pode fazê-lo usando uma simples ação before em seu 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 O procedimento acima funciona para quaisquer campos adicionais onde os parâmetros são tipos escalares simples. Se você tiver atributos aninhados (digamos que esteja usando accepts_nested_attributes_for ), precisará informar o devise sobre esses aninhamentos e 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
endO Devise permite que você altere completamente os padrões do Devise ou invoque um comportamento personalizado passando um bloco:
Para permitir valores escalares simples para nome de usuário e email, use isto
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_in ) do | user_params |
user_params . permit ( :username , :email )
end
endSe você tiver algumas caixas de seleção que expressam as funções que um usuário pode assumir no registro, o navegador enviará essas caixas de seleção selecionadas como uma matriz. Um array não é um dos escalares permitidos pelo Strong Parameters, então precisamos configurar o Devise da seguinte maneira:
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_up ) do | user_params |
user_params . permit ( { roles : [ ] } , :email , :password , :password_confirmation )
end
endPara obter a lista de escalares permitidos e como declarar chaves permitidas em hashes e matrizes aninhados, consulte
https://github.com/rails/strong_parameters#nested-parameters
Se você tiver vários modelos do Devise, talvez você queira configurar um desinfetante de parâmetro diferente por modelo. Neste caso, recomendamos herdar de Devise::ParameterSanitizer e adicionar sua própria lógica:
class User :: ParameterSanitizer < Devise :: ParameterSanitizer
def initialize ( * )
super
permit ( :sign_up , keys : [ :username , :email ] )
end
endE então configure seus controladores para usá-lo:
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 O exemplo acima substitui os parâmetros permitidos para o usuário ser :username e :email . A maneira não preguiçosa de configurar parâmetros seria definindo o filtro before acima em um controlador personalizado. Detalhamos como configurar e personalizar controladores em algumas seções abaixo.
Construímos o Devise para ajudá-lo a desenvolver rapidamente um aplicativo que usa autenticação. No entanto, não queremos atrapalhar quando você precisar personalizá-lo.
Como o Devise é um mecanismo, todas as suas visualizações são empacotadas dentro da gema. Essas visualizações ajudarão você a começar, mas depois de algum tempo você poderá querer alterá-las. Se for esse o caso, basta invocar o seguinte gerador e ele copiará todas as visualizações para sua aplicação:
rails generate devise:views Se você tiver mais de um modelo do Devise em sua aplicação (como User e Admin ), notará que o Devise usa as mesmas visualizações para todos os modelos. Felizmente, o Devise oferece uma maneira fácil de personalizar visualizações. Tudo que você precisa fazer é definir config.scoped_views = true dentro do arquivo config/initializers/devise.rb .
Depois de fazer isso, você poderá ter visualizações baseadas na função, como users/sessions/new e admins/sessions/new . Se nenhuma visualização for encontrada dentro do escopo, o Devise usará a visualização padrão em devise/sessions/new . Você também pode usar o gerador para gerar visualizações com escopo definido:
rails generate devise:views users Se desejar gerar apenas alguns conjuntos de visualizações, como aqueles para o módulo registerable e confirmable , você pode passar uma lista de visualizações para o gerador com o sinalizador -v .
rails generate devise:views -v registrations confirmationsSe a personalização no nível das visualizações não for suficiente, você pode personalizar cada controlador seguindo estas etapas:
Crie seus controladores personalizados usando o gerador que requer um escopo:
rails generate devise:controllers [scope] Se você especificar users como escopo, os controladores serão criados em app/controllers/users/ . E o controlador de sessões ficará assim:
class Users :: SessionsController < Devise :: SessionsController
# GET /resource/sign_in
# def new
# super
# end
...
end Use o sinalizador -c para especificar um ou mais controladores, por exemplo: rails generate devise:controllers users -c sessions
Diga ao roteador para usar este controlador:
devise_for :users , controllers : { sessions : 'users/sessions' } Recomendado, mas não obrigatório: copie (ou mova) as visualizações de devise/sessions para users/sessions . O Rails continuará usando as visualizações do devise/sessions devido à herança se você pular esta etapa, mas ter as visualizações correspondentes ao(s) controlador(es) mantém as coisas consistentes.
Finalmente, altere ou estenda as ações desejadas do controlador.
Você pode substituir completamente uma ação do controlador:
class Users :: SessionsController < Devise :: SessionsController
def create
# custom sign-in code
end
endOu você pode simplesmente adicionar um novo comportamento a ele:
class Users :: SessionsController < Devise :: SessionsController
def create
super do | resource |
BackgroundWorker . trigger ( resource )
end
end
endIsso é útil para acionar trabalhos em segundo plano ou registrar eventos durante determinadas ações.
Lembre-se de que o Devise usa mensagens flash para informar aos usuários se o login foi bem-sucedido ou malsucedido. O Devise espera que seu aplicativo chame flash[:notice] e flash[:alert] conforme apropriado. Não imprima o hash flash inteiro, imprima apenas chaves específicas. Em algumas circunstâncias, o Devise adiciona uma chave :timedout ao hash flash, que não se destina à exibição. Remova esta chave do hash se pretende imprimir o hash inteiro.
O Devise também vem com rotas padrão. Se você precisar personalizá-los, provavelmente poderá fazê-lo por meio do método devise_for. Aceita diversas opções como :class_name, :path_prefix e assim por diante, incluindo a possibilidade de alterar nomes de caminhos 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' } Certifique-se de verificar a documentação devise_for para obter detalhes.
Se você precisar de uma personalização mais profunda, por exemplo, para permitir também "/sign_in" além de "/users/sign_in", tudo o que você precisa fazer é criar suas rotas normalmente e envolvê-las em um bloco devise_scope no roteador:
devise_scope :user do
get 'sign_in' , to : 'devise/sessions#new'
end Dessa forma, você diz ao Devise para usar o escopo :user quando "/sign_in" for acessado. Observe devise_scope também tem o alias as seu roteador.
Observação: você ainda precisará adicionar devise_for em suas rotas para usar métodos auxiliares como current_user .
devise_for :users , skip : :allO Devise se integra ao Hotwire/Turbo tratando essas solicitações como navegacionais e configurando certas respostas para erros e redirecionamentos para corresponder ao comportamento esperado. Novos aplicativos são gerados com a seguinte configuração de resposta por padrão, e os aplicativos existentes podem aceitar adicionando a configuração aos inicializadores do 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 : essas respostas personalizadas exigem que a versão do gem responders seja 3.1.0 ou superior. Certifique-se de atualizá-la se for usar esta configuração. Verifique este guia de atualização para obter mais informações.
Nota : a configuração dos status acima pode se tornar o padrão para o Devise em uma versão futura.
Existem algumas outras alterações que você pode precisar fazer em seu aplicativo para funcionar com Hotwire/Turbo, se estiver migrando do rails-ujs:
data-confirm que adiciona um modal de confirmação aos botões/formulários antes do envio precisa mudar para data-turbo-confirm , para que o Turbo lide com isso adequadamente.data-method que define o método de solicitação para envios de links precisa mudar para data-turbo-method . Isso não é necessário para button_to ou form s, pois o Turbo pode lidar com eles. Se você estiver configurando o Devise para sair via :delete e estiver usando links (em vez de botões agrupados em um formulário) para sair com o method: :delete opção, eles precisarão ser atualizados conforme descrito acima. (O Devise não fornece links/botões de saída em suas visualizações compartilhadas.)
Certifique-se de inspecionar suas visualizações procurando por elas e altere-as adequadamente.
O Devise usa mensagens flash com I18n, em conjunto com as teclas flash :notice e :alert. Para personalizar seu aplicativo, você pode configurar seu arquivo de localidade:
en :
devise :
sessions :
signed_in : ' Signed in successfully. 'Você também pode criar mensagens distintas com base no recurso configurado usando o nome singular fornecido nas rotas:
en :
devise :
sessions :
user :
signed_in : ' Welcome user, you are signed in. '
admin :
signed_in : ' Hello admin! 'O mailer Devise usa um padrão semelhante para criar mensagens de assunto:
en :
devise :
mailer :
confirmation_instructions :
subject : ' Hello everybody! '
user_subject : ' Hello User! Please confirm your email '
reset_password_instructions :
subject : ' Reset instructions 'Dê uma olhada em nosso arquivo de localidade para verificar todas as mensagens disponíveis. Você também pode estar interessado em uma das muitas traduções disponíveis em nosso wiki:
https://github.com/heartcombo/devise/wiki/I18n
Cuidado: Devise Controllers herdam de ApplicationController. Se seu aplicativo usa vários códigos de idioma, você deve definir I18n.locale em ApplicationController.
O Devise inclui alguns auxiliares de teste para testes de controlador e integração. Para usá-los, você precisa incluir o respectivo módulo em seus casos/especificações de teste.
Os testes de controlador exigem que você inclua Devise::Test::IntegrationHelpers em seu caso de teste ou em sua superclasse pai ActionController::TestCase . Para versões Rails anteriores à 5, inclua Devise::Test::ControllerHelpers em vez disso, já que a superclasse para testes de controlador foi alterada para ActionDispatch::IntegrationTest (para mais detalhes, veja a seção Testes de integração).
class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: IntegrationHelpers # Rails >= 5
end class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: ControllerHelpers # Rails < 5
end Se estiver usando RSpec, você pode colocar o seguinte dentro de um arquivo chamado spec/support/devise.rb ou em seu spec/spec_helper.rb (ou spec/rails_helper.rb se estiver usando rspec-rails ):
RSpec . configure do | config |
config . include Devise :: Test :: ControllerHelpers , type : :controller
config . include Devise :: Test :: ControllerHelpers , type : :view
end Apenas certifique-se de que esta inclusão seja feita após a diretiva require 'rspec/rails' .
Agora você está pronto para usar os métodos sign_in e sign_out nos testes do seu controlador:
sign_in @user
sign_in @user , scope : :adminSe você estiver testando os controladores internos do Devise ou um controlador que herda dos controladores do Devise, será necessário informar ao Devise qual mapeamento deve ser usado antes de uma solicitação. Isto é necessário porque o Devise obtém essas informações do roteador, mas como os testes do controlador não passam pelo roteador, elas precisam ser declaradas explicitamente. Por exemplo, se você estiver testando o escopo do usuário, basta usar:
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 Auxiliares de teste de integração estão disponíveis incluindo o módulo Devise::Test::IntegrationHelpers .
class PostsTests < ActionDispatch :: IntegrationTest
include Devise :: Test :: IntegrationHelpers
end Agora você pode usar os seguintes métodos sign_in e sign_out em seus testes de integração:
sign_in users ( :bob )
sign_in users ( :bob ) , scope : :admin
sign_out :user Os usuários do RSpec podem incluir o módulo IntegrationHelpers em suas especificações :feature .
RSpec . configure do | config |
config . include Devise :: Test :: IntegrationHelpers , type : :feature
end Ao contrário dos testes de controlador, os testes de integração não precisam fornecer o valor devise.mapping env , pois o mapeamento pode ser inferido pelas rotas executadas em seus testes.
Você pode ler mais sobre como testar seus controladores Rails com RSpec no wiki:
O Devise vem com suporte OmniAuth pronto para uso para autenticação com outros provedores. Para usá-lo, basta especificar sua configuração OmniAuth em config/initializers/devise.rb :
config . omniauth :github , 'APP_ID' , 'APP_SECRET' , scope : 'user,public_repo'Você pode ler mais sobre o suporte OmniAuth no wiki:
O Devise permite que você configure quantos modelos do Devise desejar. Se você deseja ter um modelo Admin apenas com recursos de autenticação e timeout, além do modelo User acima, basta executar:
# 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, você pode simplesmente executar o gerador Devise.
Lembre-se de que esses modelos terão rotas completamente diferentes. Eles não compartilham e não podem compartilhar o mesmo controlador para entrar, sair e assim por diante. Caso você queira ter funções diferentes compartilhando as mesmas ações, recomendamos que você use uma abordagem baseada em funções, fornecendo uma coluna de funções ou usando uma gem dedicada para autorização.
Se você estiver usando o Active Job para entregar mensagens do Action Mailer em segundo plano por meio de um back-end de fila, poderá enviar e-mails do Devise por meio de sua fila existente, substituindo o método send_devise_notification em seu modelo.
def send_devise_notification ( notification , * args )
devise_mailer . send ( notification , self , * args ) . deliver_later
endSe você ativar o módulo Recuperável, observe que um token de redefinição de senha roubado pode dar a um invasor acesso ao seu aplicativo. O Devise se esforça para gerar tokens aleatórios e seguros e armazena apenas resumos de tokens no banco de dados, nunca texto simples. No entanto, o comportamento de log padrão no Rails pode fazer com que tokens de texto simples vazem para arquivos de log:
deliver_later para enviar e-mails de redefinição de senha, os tokens de redefinição de senha vazarão. Rails define o nível do logger de produção como INFO por padrão. Considere alterar o nível do seu registrador de produção para WARN se desejar evitar que tokens vazem em seus logs. Em config/environments/production.rb :
config . log_level = :warnO Devise suporta ActiveRecord (padrão) e Mongoid. Para selecionar outro ORM, basta solicitá-lo no arquivo inicializador.
Rails 5+ possui um modo API integrado que otimiza Rails para uso como API (apenas). O Devise é capaz de lidar com aplicativos construídos neste modo sem modificações adicionais, no sentido de que não deve gerar exceções e coisas do gênero. Mas alguns problemas ainda podem surgir durante development / testing , pois ainda não sabemos toda a extensão dessa compatibilidade. (Para mais informações, consulte a edição nº 4947)
Os aplicativos somente API não suportam autenticação baseada em navegador por meio de cookies, que é o padrão do dispositivo. No entanto, o devise ainda pode fornecer autenticação imediata nesses casos com a estratégia http_authenticatable , que usa HTTP Basic Auth e autentica o usuário em cada solicitação. (Para obter mais informações, consulte este artigo wiki sobre Como usar a autenticação básica HTTP)
O padrão do devise para HTTP Auth está desabilitado, então ele precisará ser habilitado no inicializador do devise para a estratégia de banco de dados:
config . http_authenticatable = [ :database ]Esta restrição não o impede de implementar estratégias personalizadas de Warden, seja em seu aplicativo ou por meio de extensões baseadas em gemas para desenvolvimento. Uma estratégia de autenticação comum para APIs é a autenticação baseada em token. Para obter mais informações sobre como estender o devise para oferecer suporte a esse tipo de autenticação e outros, consulte o artigo wiki sobre exemplos e alternativas de autenticação de token simples ou esta postagem do blog sobre métodos de autenticação personalizados com o Devise.
O Modo API altera a ordem da pilha de middleware e isso pode causar problemas para Devise::Test::IntegrationHelpers . Esse problema geralmente surge como um undefined method `[]=' for nil:NilClass ao usar auxiliares de teste de integração, como #sign_in . A solução é simplesmente reordenar os middlewares adicionando o seguinte ao test.rb:
Rails . application
