devise
v4.9.4
Devise は、Warden をベースとした Rails 用の柔軟な認証ソリューションです。それ：
10 個のモジュールで構成されています。
Devise Wiki には、多くの「ハウツー」記事や最もよくある質問への回答など、Devise に関する追加情報がたくさんあります。この README を読み終えた後、Wiki を参照してください。
https://github.com/heartcombo/devise/wiki
Devise に関する問題を発見した場合は、それについてお知らせください。ただし、バグレポートを送信する前に、次のガイドラインを確認してください。
https://github.com/heartcombo/devise/wiki/Bug-reports
セキュリティ関連のバグを発見した場合は、GitHub 問題トラッカーを使用しないでください。 [email protected] にメールを送信してください。
質問、コメント、懸念事項がある場合は、GitHub 問題トラッカーの代わりに StackOverflow を使用してください。
http://stackoverflow.com/questions/tagged/devise
非推奨のメーリング リストは引き続き読むことができます
https://groups.google.com/group/plataformatec-devise
ここで Devise ドキュメントを RDoc 形式で表示できます。
http://rubydoc.info/github/heartcombo/devise/main/frames
以前のバージョンの Rails で Devise を使用する必要がある場合は、gem をインストールした後いつでもコマンド ラインから「gem サーバー」を実行して古いドキュメントにアクセスできます。
GitHub には、さまざまなバージョンの Rails を使用した Devise のさまざまな機能を示すサンプル アプリケーションがいくつかあります。ここで見ることができます:
https://github.com/heartcombo/devise/wiki/Example-Applications
私たちのコミュニティは、Devise に含まれている機能を超える機能を追加する多数の拡張機能を作成しました。ここで利用可能な拡張機能のリストを表示し、独自の拡張機能を追加できます。
https://github.com/heartcombo/devise/wiki/Extensions
ぜひ Devise への貢献をご検討ください。開始方法については、この短い概要をお読みください。
https://github.com/heartcombo/devise/wiki/Contributing
通常は、変更に対するテストを作成する必要があります。テスト スイートを実行するには、Devise の最上位ディレクトリに移動し、 bundle installおよびbin/test実行します。 Devise は、複数の Ruby および Rails バージョン、および ActiveRecord および Mongoid ORM で動作します。つまり、いくつかの修飾子DEVISE_ORMおよびBUNDLE_GEMFILEを使用してテスト スイートを実行できます。
Devise は Mongoid と ActiveRecord の両方をサポートしているため、この変数を利用して各 ORM の特定のコードを実行します。 DEVISE_ORMのデフォルト値はactive_recordです。 Mongoid のテストを実行するには、 mongoid渡すことができます。
DEVISE_ORM=mongoid bin/test
==> Devise.orm = :mongoid
Mongoid のテストを実行するときは、システム上で MongoDB サーバー (バージョン 2.0 以降) が実行されている必要があります。
コマンド出力には、使用されている変数値が表示されることに注意してください。
この変数を使用して、(現在のディレクトリにあるものではなく) どの Gemfile を使用する必要があるかをバンドラーに指示できます。 gemfiles ディレクトリ内には、サポートする Rails のバージョンごとに 1 つあります。プル リクエストを送信すると、テスト スイートの一部を使用するとテスト スイートが破損する場合があります。その場合は、 BUNDLE_GEMFILE変数を使用して同じ環境をシミュレートできます。たとえば、Ruby 3.0.0 と Rails 6.0 を使用してテストが失敗した場合は、次のことができます。
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/testMongoid のテストが失敗した場合は、両方を組み合わせることもできます。
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 DEVISE_ORM=mongoid bin/testDevise はテスト フレームワークとして Mini Test を使用します。
bin/testbin/test test/models/trackable_test.rbbin/test test/models/trackable_test.rb:16初めて Rails アプリケーションを構築する場合は、Devise を使用しないことをお勧めします。 Devise には、Rails フレームワークをよく理解する必要があります。このような場合は、簡単な認証システムを最初から構築することをお勧めします。開始に役立ついくつかのリソースを次に示します。
Rails と認証メカニズムについての理解をしっかりと深めれば、Devise を非常に快適に操作できるようになるでしょう。 ?
Devise 4.0 は Rails 6.0 以降で動作します。走る：
bundle add devise次に、ジェネレーターを実行する必要があります。
rails generate devise:installこの時点で、コンソールにいくつかの指示が表示されます。これらの手順の中で、各環境で Devise メーラーのデフォルトの URL オプションを設定する必要があります。 config/environments/development.rbの可能な構成は次のとおりです。
config . action_mailer . default_url_options = { host : 'localhost' , port : 3000 }ジェネレーターは、Devise のすべての構成オプションを記述するイニシャライザーをインストールします。ぜひ一度見てみてください。完了したら、ジェネレーターを使用して任意のモデルに Devise を追加する準備が整います。
次のコマンドでは、 MODELアプリケーションのユーザーに使用されるクラス名に置き換えます (通常はUserですが、 Adminの場合もあります)。これにより、モデルが作成され (モデルが存在しない場合)、デフォルトの Devise モジュールを使用して設定されます。また、ジェネレーターは、Devise コントローラーを指すようにconfig/routes.rbファイルを構成します。
rails generate devise MODEL次に、確認可能またはロック可能など、追加する必要がある追加の構成オプションがないかモデルを確認します。オプションを追加する場合は、必ず移行ファイル (ORM がサポートしている場合はジェネレーターによって作成される) を検査し、適切なセクションのコメントを解除してください。たとえば、モデルに確認可能オプションを追加する場合は、移行の確認可能セクションのコメントを解除する必要があります。
次に、 rails db:migrateを実行します。
Devise の構成オプションを変更した後は、アプリケーションを再起動する必要があります (これにはスプリングの停止も含まれます)。そうしないと、ユーザーがログインできなくなったり、ヘルパーのルートが未定義になったりするなど、奇妙なエラーが発生します。
Devise は、コントローラーとビュー内で使用するヘルパーをいくつか作成します。ユーザー認証を使用してコントローラーを設定するには、次の before_action を追加するだけです (デバイスのモデルが「ユーザー」であると仮定します)。
before_action :authenticate_user! Rails 5 では、 protect_from_forgeryがbefore_actionチェーンの前に付加されなくなったことに注意してください。そのため、 protect_from_forgery前にauthenticate_user設定した場合、リクエストの結果は「CSRF トークンの信頼性を検証できません」という結果になります。これを解決するには、呼び出す順序を変更するか、 protect_from_forgery prepend: trueを使用します。
デバイスのモデルが User 以外の場合は、「_user」を「_yourmodel」に置き換えます。同じロジックが以下の命令にも適用されます。
ユーザーがサインインしているかどうかを確認するには、次のヘルパーを使用します。
user_signed_in?現在サインインしているユーザーは、次のヘルパーを利用できます。
current_userこのスコープのセッションにアクセスできます。
user_sessionユーザーのサインイン、アカウントの確認、またはパスワードの更新後、Devise はリダイレクト先のスコープ付きルート パスを探します。たとえば、 :userリソースを使用する場合、 user_root_pathが存在する場合はそれが使用されます。それ以外の場合は、デフォルトのroot_pathが使用されます。これは、ルート内にルートを設定する必要があることを意味します。
root to : 'home#index' after_sign_in_path_forとafter_sign_out_path_forをオーバーライドして、リダイレクト フックをカスタマイズすることもできます。
たとえば、Devise モデルの名前がUserではなくMemberである場合、利用可能なヘルパーは次のとおりであることに注意してください。
before_action :authenticate_member!
member_signed_in?
current_member
member_sessionモデルの Devise メソッドは、モジュールを構成するためのいくつかのオプションも受け入れます。たとえば、次のようにハッシュ アルゴリズムのコストを選択できます。
devise :database_authenticatable , :registerable , :confirmable , :recoverable , stretches : 13 :stretchesのほかに、 :pepper 、 :encryptor 、 :confirm_within 、 :remember_for 、 :timeout_in 、 :unlock_inなどのオプションを定義できます。詳細については、上記の「devise:install」ジェネレーターを呼び出したときに作成された初期化ファイルを参照してください。このファイルは通常、 /config/initializers/devise.rbにあります。
Devise 4 ではパラメータサニタイザー API が変更されました
Devise の以前のバージョンについては、https://github.com/heartcombo/devise/tree/3-stable#strong-parameters を参照してください。
独自のビューをカスタマイズすると、フォームに新しい属性を追加することになる場合があります。 Rails 4 ではパラメーターのサニタイズがモデルからコントローラーに移されたため、Devise はこの問題をコントローラーでも処理できるようになりました。
Devise には、パラメータのセットをモデルに渡すことを可能にするアクションが 3 つしかないため、サニタイズが必要になります。それらの名前とデフォルトで許可されるパラメータは次のとおりです。
sign_in ( Devise::SessionsController#create ) - 認証キー ( emailなど) のみを許可します。sign_up ( Devise::RegistrationsController#create ) - 認証キーとpasswordおよびpassword_confirmationを許可します。account_update ( Devise::RegistrationsController#update ) - 認証キーに加えて、 password 、 password_confirmation 、 current_passwordを許可します。追加のパラメーターを許可したい場合 (lazy way™)、 ApplicationControllerで単純な before アクションを使用して許可できます。
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上記は、パラメーターが単純なスカラー型である追加フィールドに対して機能します。ネストされた属性がある場合 ( accepts_nested_attributes_forを使用しているとします)、それらのネストと型について Device に伝える必要があります。
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 を使用すると、ブロックを渡すことで Devise のデフォルトを完全に変更したり、カスタム動作を呼び出すことができます。
ユーザー名と電子メールに単純なスカラー値を許可するには、これを使用します
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_in ) do | user_params |
user_params . permit ( :username , :email )
end
endユーザーが登録時に引き受けることができる役割を表すチェックボックスがいくつかある場合、ブラウザはそれらの選択されたチェックボックスを配列として送信します。配列は Strong Parameters で許可されているスカラーの 1 つではないため、次の方法で Devise を構成する必要があります。
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_up ) do | user_params |
user_params . permit ( { roles : [ ] } , :email , :password , :password_confirmation )
end
end許可されるスカラーのリスト、およびネストされたハッシュおよび配列で許可されるキーを宣言する方法については、を参照してください。
https://github.com/rails/strong_parameters#nested-parameters
複数の Devise モデルがある場合は、モデルごとに異なるパラメータ サニタイザーを設定することができます。この場合、 Devise::ParameterSanitizerから継承し、独自のロジックを追加することをお勧めします。
class User :: ParameterSanitizer < Devise :: ParameterSanitizer
def initialize ( * )
super
permit ( :sign_up , keys : [ :username , :email ] )
end
end次に、それを使用するようにコントローラーを設定します。
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上の例では、ユーザーに許可されているパラメータを:usernameと:emailの両方にオーバーライドします。パラメーターを遅延なく構成する方法は、カスタム コントローラーで上記の前フィルターを定義することです。以下のいくつかのセクションで、コントローラーを構成およびカスタマイズする方法について詳しく説明します。
私たちは、認証を使用するアプリケーションを迅速に開発できるようにするために Devise を構築しました。ただし、カスタマイズする必要があるときに邪魔になることは望ましくありません。
Devise はエンジンであるため、そのビューはすべて gem 内にパッケージ化されています。これらのビューは開始時に役立ちますが、しばらくすると変更したくなる場合があります。この場合、次のジェネレーターを呼び出すだけで、すべてのビューがアプリケーションにコピーされます。
rails generate devise:viewsアプリケーション内に複数の Devise モデル ( UserやAdminなど) がある場合、Devise はすべてのモデルに対して同じビューを使用することがわかります。幸いなことに、Devise はビューをカスタマイズする簡単な方法を提供します。必要なのは、 config/initializers/devise.rbファイル内でconfig.scoped_views = trueを設定することだけです。
これを行うと、 users/sessions/newやadmins/sessions/newなどのロールに基づいたビューを持つことができるようになります。スコープ内にビューが見つからない場合、Devise はdevise/sessions/newにあるデフォルトのビューを使用します。ジェネレーターを使用してスコープ付きビューを生成することもできます。
rails generate devise:views users registerableおよびconfirmableモジュールのビューなど、少数のビューのセットのみを生成したい場合は、 -vフラグを使用してビューのリストをジェネレーターに渡すことができます。
rails generate devise:views -v registrations confirmationsビュー レベルでのカスタマイズが十分でない場合は、次の手順に従って各コントローラーをカスタマイズできます。
スコープを必要とするジェネレーターを使用してカスタム コントローラーを作成します。
rails generate devise:controllers [scope]スコープとしてusers指定すると、コントローラーはapp/controllers/users/に作成されます。セッション コントローラーは次のようになります。
class Users :: SessionsController < Devise :: SessionsController
# GET /resource/sign_in
# def new
# super
# end
...
end -cフラグを使用して 1 つ以上のコントローラーを指定します。たとえば、 rails generate devise:controllers users -c sessions
このコントローラを使用するようにルーターに指示します。
devise_for :users , controllers : { sessions : 'users/sessions' }必須ではありませんが推奨: ビューをdevise/sessionsからusers/sessionsにコピー (または移動) します。この手順を省略した場合、Rails は継承によりdevise/sessionsからのビューを引き続き使用しますが、コントローラーに一致するビューを持つことで一貫性が保たれます。
最後に、必要なコントローラーのアクションを変更または拡張します。
コントローラーのアクションを完全にオーバーライドできます。
class Users :: SessionsController < Devise :: SessionsController
def create
# custom sign-in code
end
endまたは、単純に新しい動作を追加することもできます。
class Users :: SessionsController < Devise :: SessionsController
def create
super do | resource |
BackgroundWorker . trigger ( resource )
end
end
endこれは、バックグラウンド ジョブをトリガーしたり、特定のアクション中にイベントをログに記録したりする場合に役立ちます。
Devise はフラッシュ メッセージを使用して、サインインが成功したか失敗したかをユーザーに知らせることに注意してください。 Devise は、アプリケーションが必要に応じてflash[:notice]およびflash[:alert]を呼び出すことを期待します。フラッシュ ハッシュ全体を出力せず、特定のキーのみを出力します。状況によっては、Devise は表示を目的としていない:timedoutキーをフラッシュ ハッシュに追加します。ハッシュ全体を出力する場合は、ハッシュからこのキーを削除します。
Devise にはデフォルト ルートも付属しています。カスタマイズする必要がある場合は、おそらく、device_for メソッドを通じて実行できるはずです。 I18n のパス名を変更する可能性を含む、:class_name、:path_prefix などのいくつかのオプションを受け入れます。
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' }詳細については、 devise_forドキュメントを必ず確認してください。
たとえば、「/users/sign_in」に加えて「/sign_in」も許可するなど、より詳細なカスタマイズが必要な場合は、通常どおりルートを作成し、ルーターのdevise_scopeブロックでラップするだけです。
devise_scope :user do
get 'sign_in' , to : 'devise/sessions#new'
endこのようにして、「/sign_in」にアクセスするときにスコープ:user使用するように Devise に指示します。 devise_scopeもルーターとasにエイリアスになっていることに注意してください。
注意: current_userなどのヘルパー メソッドを使用するには、ルートにdevise_forを追加する必要があります。
devise_for :users , skip : :allDevise は、そのようなリクエストをナビゲーションとして扱い、予想される動作に一致するようにエラーやリダイレクトに対する特定の応答を構成することにより、Hotwire/Turbo と統合します。新しいアプリはデフォルトで次の応答構成で生成され、既存のアプリはその構成を 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重要: これらのカスタム応答では、 responders gem バージョンが3.1.0以降である必要があります。この構成を使用する場合は、必ず更新してください。詳細については、このアップグレード ガイドを確認してください。
注: 上記のステータス設定は、将来のリリースでは Devise のデフォルトになる可能性があります。
Rails-ujs から移行する場合、Hotwire/Turbo で動作するようにアプリに加える必要がある変更が他にもいくつかあります。
data-confirmオプションは、Turbo がそれらを適切に処理できるように、 data-turbo-confirmに変更する必要があります。data-methodオプションをdata-turbo-methodに変更する必要があります。 button_toやformについては Turbo が処理できるため、これは必要ありません。 Devise を:delete経由でサインアウトするように設定しており、(フォームにラップされたボタンの代わりに) リンクを使用してmethod: :deleteオプションでサインアウトしている場合は、上記のように更新する必要があります。 (Devise は共有ビューにサインアウト リンク/ボタンを提供しません。)
ビューを調べてそれらを探し、適切に変更してください。
Devise は、フラッシュ キー :notice および :alert と組み合わせて、I18n のフラッシュ メッセージを使用します。アプリをカスタマイズするには、ロケール ファイルを設定します。
en :
devise :
sessions :
signed_in : ' Signed in successfully. 'ルートで指定した単数形の名前を使用して、構成したリソースに基づいて個別のメッセージを作成することもできます。
en :
devise :
sessions :
user :
signed_in : ' Welcome user, you are signed in. '
admin :
signed_in : ' Hello admin! 'Devise メーラーは、同様のパターンを使用して件名のメッセージを作成します。
en :
devise :
mailer :
confirmation_instructions :
subject : ' Hello everybody! '
user_subject : ' Hello User! Please confirm your email '
reset_password_instructions :
subject : ' Reset instructions 'ロケール ファイルを見て、利用可能なすべてのメッセージを確認してください。私たちの Wiki で利用できる多くの翻訳の中の 1 つに興味があるかもしれません。
https://github.com/heartcombo/devise/wiki/I18n
注意: Devise コントローラは ApplicationController を継承します。アプリが複数のロケールを使用する場合は、必ず ApplicationController で I18n.locale を設定する必要があります。
Devise には、コントローラー テストと統合テスト用のテスト ヘルパーがいくつか含まれています。これらを使用するには、テスト ケース/仕様にそれぞれのモジュールを含める必要があります。
コントローラー テストでは、テスト ケースまたはその親ActionController::TestCaseスーパークラスにDevise::Test::IntegrationHelpers含める必要があります。 Rails バージョン 5 より前の場合は、コントローラー テストのスーパークラスが ActionDispatch::IntegrationTest に変更されたため、代わりにDevise::Test::ControllerHelpers含めてください (詳細については、統合テストのセクションを参照してください)。
class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: IntegrationHelpers # Rails >= 5
end class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: ControllerHelpers # Rails < 5
end RSpec を使用している場合は、 spec/support/devise.rbという名前のファイル内、またはspec/spec_helper.rb ( rspec-railsを使用している場合はspec/rails_helper.rb ) に次の内容を置くことができます。
RSpec . configure do | config |
config . include Devise :: Test :: ControllerHelpers , type : :controller
config . include Devise :: Test :: ControllerHelpers , type : :view
endこのインクルードはrequire 'rspec/rails'ディレクティブの後に行うようにしてください。
これで、コントローラー テストでsign_inとsign_outメソッドを使用する準備が整いました。
sign_in @user
sign_in @user , scope : :adminDevise の内部コントローラーまたは Devise から継承するコントローラーをテストしている場合は、リクエストの前にどのマッピングを使用する必要があるかを Devise に指示する必要があります。 Devise はこの情報をルーターから取得するため、これが必要ですが、コントローラーのテストはルーターを経由しないため、明示的に指定する必要があります。たとえば、ユーザー スコープをテストする場合は、次のように単純に使用します。
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統合テスト ヘルパーはDevise::Test::IntegrationHelpersモジュールを含めることで利用できます。
class PostsTests < ActionDispatch :: IntegrationTest
include Devise :: Test :: IntegrationHelpers
endこれで、統合テストで次のsign_inとsign_outメソッドを使用できるようになりました。
sign_in users ( :bob )
sign_in users ( :bob ) , scope : :admin
sign_out :user RSpec ユーザーは、 IntegrationHelpersモジュールを:feature仕様に含めることができます。
RSpec . configure do | config |
config . include Devise :: Test :: IntegrationHelpers , type : :feature
endコントローラー テストとは異なり、統合テストでは、テストで実行されるルートによってマッピングを推測できるため、 devise.mapping env値を指定する必要はありません。
RSpec を使用した Rails コントローラーのテストについて詳しくは、wiki を参照してください。
Devise には、他のプロバイダーで認証するための OmniAuth サポートがすぐに付属しています。これを使用するには、 config/initializers/devise.rbで OmniAuth 構成を指定するだけです。
config . omniauth :github , 'APP_ID' , 'APP_SECRET' , scope : 'user,public_repo'OmniAuth サポートの詳細については、Wiki を参照してください。
Devise では、必要なだけ Devise モデルをセットアップできます。上記の User モデルに加えて、認証とタイムアウト機能のみを備えた Admin モデルが必要な場合は、次を実行するだけです。
# 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_sessionあるいは、単に Devise ジェネレーターを実行することもできます。
これらのモデルはルートがまったく異なることに注意してください。サインインやサインアウトなどのために同じコントローラーを共有することはありませんし、共有することもできません。同じアクションを異なるロールで共有する場合は、ロール列を提供するか、承認用の専用 gem を使用することにより、ロールベースのアプローチを使用することをお勧めします。
アクティブ ジョブを使用して、キューイング バックエンドを通じてバックグラウンドでアクション メーラー メッセージを配信している場合は、モデルのsend_devise_notificationメソッドをオーバーライドすることで、既存のキューを通じて Devise 電子メールを送信できます。
def send_devise_notification ( notification , * args )
devise_mailer . send ( notification , self , * args ) . deliver_later
end回復可能モジュールを有効にする場合は、盗まれたパスワード リセット トークンによって攻撃者がアプリケーションにアクセスできる可能性があることに注意してください。 Devise は、ランダムで安全なトークンを生成することに労力を費やし、平文ではなくトークン ダイジェストのみをデータベースに保存します。ただし、Rails のデフォルトのロギング動作により、平文トークンがログ ファイルに漏洩する可能性があります。
deliver_later使用してパスワード リセット電子メールを送信するように設定すると、パスワード リセット トークンが漏洩します。 Rails は、デフォルトで本番ロガー レベルを INFO に設定します。トークンがログに漏洩するのを防ぎたい場合は、運用ロガー レベルを WARN に変更することを検討してください。 config/environments/production.rb内:
config . log_level = :warnDevise は ActiveRecord (デフォルト) と Mongoid をサポートしています。別の ORM を選択するには、初期化ファイルでそれを要求するだけです。
Rails 5 以降には、Rails を API (のみ) として使用するために最適化する API モードが組み込まれています。 Devise は、例外などを発生させないという意味で、追加の変更を加えることなく、このモードで構築されたアプリケーションをある程度処理できます。ただし、この互換性の全容がまだわかっていないため、 development / testing中にいくつかの問題が発生する可能性があります。 (詳細については、問題 #4947 を参照してください)
API 専用アプリケーションは、デバイスのデフォルトである Cookie によるブラウザベースの認証をサポートしていません。それでも、Devices は、HTTP 基本認証を使用し、リクエストごとにユーザーを認証するhttp_authenticatable戦略を使用して、そのような場合でもすぐに使用できる認証を提供できます。 (詳細については、この Wiki 記事「方法: HTTP 基本認証を使用する」を参照してください)
HTTP 認証のデバイスのデフォルトは無効になっているため、データベース戦略のデバイス初期化子で有効にする必要があります。
config . http_authenticatable = [ :database ]この制限は、アプリケーション内で、またはデバイス用の gem ベースの拡張機能を介して、カスタムの監視戦略を実装することを制限するものではありません。 API の一般的な認証戦略は、トークンベースの認証です。このタイプの認証やその他の認証をサポートするように Device を拡張する方法の詳細については、単純なトークン認証の例と代替手段に関する Wiki 記事、または Devise を使用したカスタム認証方法に関するこのブログ投稿を参照してください。
API モードではミドルウェア スタックの順序が変更されるため、 Devise::Test::IntegrationHelpersで問題が発生する可能性があります。この問題は通常、 #sign_inなどの統合テスト ヘルパーを使用するときに、 undefined method `[]=' for nil:NilClassエラーとして表面化します。解決策は、test.rb に以下を追加してミドルウェアの順序を変更するだけです。
Rails . application
