devise - Warden を使用した Rails の柔軟な認証ソリューション。

(Flexible authentication solution for Rails with Warden.)

Created at: 2009-09-16 20:15:12
Language: Ruby
License: MIT

工夫のロゴ

コードの気候

Devise は、Warden に基づく Rails 用の柔軟な認証ソリューションです。これ:

  • ラックベースです。
  • Rails エンジンに基づく完全な MVC ソリューションです。
  • 複数のモデルを同時にサインインさせることができます。
  • モジュール性の概念に基づいています: 本当に必要なものだけを使用してください。

10 個のモジュールで構成されています。

  • Database Authenticatable : パスワードをハッシュしてデータベースに保存し、サインイン中にユーザーの認証性を検証します。認証は、POST 要求または HTTP 基本認証の両方を介して実行できます。
  • Omniauthable : OmniAuth ( https://github.com/omniauth/omniauth ) サポートを追加します。
  • 確認可能: 確認手順が記載された電子メールを送信し、サインイン中にアカウントが既に確認されているかどうかを確認します。
  • 回復可能: ユーザーのパスワードをリセットし、リセット手順を送信します。
  • Registerable : 登録プロセスを通じてユーザーのサインアップを処理し、ユーザーが自分のアカウントを編集および破棄できるようにします。
  • Rememberable : 保存された Cookie からユーザーを記憶するためのトークンの生成と消去を管理します。
  • 追跡可能: サインイン数、タイムスタンプ、IP アドレスを追跡します。
  • Timeoutable : 指定された期間アクティブになっていないセッションを期限切れにします。
  • Validatable : 電子メールとパスワードの検証を提供します。これはオプションであり、カスタマイズできるため、独自の検証を定義できます。
  • Lockable : サインイン試行が指定回数失敗すると、アカウントをロックします。メールまたは指定期間後にロックを解除できます。

目次

情報

The Devise ウィキ

Devise Wiki には、多くの「ハウツー」記事やよくある質問への回答など、Devise に関する多くの追加情報があります。この README を読み終わったら、Wiki を参照してください。

https://github.com/heartcombo/devise/wiki

バグレポート

Devise で問題を発見した場合は、お知らせください。ただし、バグ レポートを送信する前に、次のガイドラインを確認してください。

https://github.com/heartcombo/devise/wiki/Bug-reports

セキュリティ関連のバグを発見した場合は、GitHub の問題トラッカーを使用しないでください。heartcombo@googlegroups.comにメールを送信します。

StackOverflow とメーリング リスト

質問、コメント、または懸念がある場合は、GitHub イシュー トラッカーの代わりに StackOverflow を使用してください。

http://stackoverflow.com/questions/tagged/devise

廃止されたメーリングリストは引き続き読むことができます

https://groups.google.com/group/plataformatec-devise

RDoc

ここで RDoc 形式の Devise ドキュメントを表示できます。

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 の最上位ディレクトリに移動し、 and を実行

bundle install
bin/test
ます。Devise は複数の Ruby および Rails バージョン、ActiveRecord および Mongoid ORM で動作します。つまり、いくつかの修飾子を使用してテスト スイートを実行でき
DEVISE_ORM
ます
BUNDLE_GEMFILE

DEVISE_ORM

Devise は Mongoid と ActiveRecord の両方をサポートしているため、この変数に依存して各 ORM の特定のコードを実行します。のデフォルト値は

DEVISE_ORM
です
active_record
。Mongoid のテストを実行するには、以下を渡すことができます
mongoid

DEVISE_ORM=mongoid bin/test

==> Devise.orm = :mongoid

Mongoid のテストを実行する場合、MongoDB サーバー (バージョン 2.0 以降) をシステムで実行する必要があります。

コマンド出力には、使用されている変数値が表示されることに注意してください。

BUNDLE_GEMFILE

この変数を使用して、バンドラーに (現在のディレクトリにあるものではなく) どの Gemfile を使用すべきかを伝えることができます。gemfilesディレクトリ内には、サポートする Rails の各バージョン用のファイルがあります。プル リクエストを送信すると、それらの一部を使用してテスト スイートが壊れる場合があります。その場合は、

BUNDLE_GEMFILE
変数を使用して同じ環境をシミュレートできます。たとえば、Ruby 2.4.2 と Rails 4.1 を使用してテストが失敗した場合は、次の操作を実行できます。

rbenv shell 2.4.2 # or rvm use 2.4.2
BUNDLE_GEMFILE=gemfiles/Gemfile.rails-4.1-stable bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile.rails-4.1-stable bin/test

Mongoid でテストが失敗した場合は、両方を組み合わせることもできます。

BUNDLE_GEMFILE=gemfiles/Gemfile.rails-4.1-stable bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile.rails-4.1-stable DEVISE_ORM=mongoid bin/test

テストの実行

Devise は、テスト フレームワークとしてMini Testを使用します。

  • すべてのテストの実行:
bin/test
  • 特定のファイルに対するテストの実行:
bin/test test/models/trackable_test.rb
  • 正規表現を指定して特定のテストを実行する:
bin/test test/models/trackable_test.rb:16

Railsから始めますか?

初めて Rails アプリケーションを作成する場合は、 Devise を使用しないことをお勧めします。Devise を使用するには、Rails フレームワークを十分に理解している必要があります。そのような場合は、簡単な認証システムをゼロから始めることをお勧めします。開始するのに役立ついくつかのリソースを次に示します。

Rails と認証メカニズムの理解が深まったら、Devise を使って楽しく作業できることを保証します。😃

入門

Devise 4.0 は Rails 4.1 以降で動作します。次の行を Gemfile に追加します。

gem 'devise'

次に実行します

bundle install

次に、ジェネレーターを実行する必要があります。

$ 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 モジュールで構成されます。ジェネレーターはまた
config/routes.rb
、Devise コントローラーを指すようにファイルを構成します。

$ rails generate devise MODEL

次に、確認可能またはロック可能など、追加する可能性のある追加の構成オプションがないかモデルを確認します。オプションを追加する場合は、必ず移行ファイル (ORM がサポートしている場合はジェネレーターによって作成されます) を調べて、適切なセクションのコメントを外してください。たとえば、モデルに確認可能オプションを追加する場合、移行の確認可能セクションのコメントを解除する必要があります。

次に実行します

rails db:migrate

Devise の設定オプションを変更した後、アプリケーションを再起動する必要があります (これには、Spring の停止が含まれます)。そうしないと、たとえば、ユーザーがログインできず、ルート ヘルパーが定義されていないなど、奇妙なエラーが発生します。

コントローラーのフィルターとヘルパー

Devise は、コントローラーとビュー内で使用するいくつかのヘルパーを作成します。ユーザー認証を使用してコントローラーをセットアップするには、この before_action を追加するだけです (デバイス モデルが「ユーザー」であると仮定します)。

before_action :authenticate_user!

Rails 5 では、がチェーン

protect_from_forgery
の先頭に追加されなくなったことに注意してください。そのため、以前に を設定した場合、リクエストは「CSRF トークンの信頼性を確認できません」という結果になります。これを解決するには、呼び出す順序を変更するか、 を使用します。
before_action
authenticate_user
protect_from_forgery
protect_from_forgery prepend: true

デバイス モデルがユーザー以外の場合は、「_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 モデルが

Member
の代わりに呼び出された
User
場合、利用可能なヘルパーは次のとおりです。

before_action :authenticate_member!

member_signed_in?

current_member

member_session

モデルの構成

モデルの Devise メソッドは、そのモジュールを構成するためのいくつかのオプションも受け入れます。たとえば、ハッシュ アルゴリズムのコストを次のように選択できます。

devise :database_authenticatable, :registerable, :confirmable, :recoverable, stretches: 13

以外にも、、、、、などのオプション

:stretches
を定義できます。詳細については、上記の「devise:install」ジェネレーターを呼び出したときに作成された初期化ファイルを参照してください。通常、このファイルは にあります。
:pepper
:encryptor
:confirm_within
:remember_for
:timeout_in
:unlock_in
/config/initializers/devise.rb

強いパラメータ

パラメータ サニタイザ API が Devise 4 で変更されました⚠️

以前の 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

追加のパラメーターを許可したい場合 (怠惰な方法™)、単純な before アクションを使用してそれを行うことができます

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

上記は、パラメーターが単純なスカラー型である追加フィールドに対して機能します。入れ子になった属性がある場合 (たとえば、 を使用している場合

accepts_nested_attributes_for
)、それらの入れ子と型についてデバイスに伝える必要があります。

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
end

Devise では、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
ます。パラメーターを構成するための怠惰でない方法は、カスタム コントローラーで上記の before フィルターを定義することです。以下のいくつかのセクションで、コントローラーを構成およびカスタマイズする方法について詳しく説明します。

ビューの構成

認証を使用するアプリケーションを迅速に開発できるように、Devise を作成しました。ただし、カスタマイズが必要な場合は邪魔になりたくありません。

Devise はエンジンであるため、そのすべてのビューは gem 内にパッケージ化されています。これらのビューは作業を開始するのに役立ちますが、しばらくすると変更したくなる場合があります。この場合、次のジェネレーターを呼び出すだけで、すべてのビューがアプリケーションにコピーされます。

$ rails generate devise:views

アプリケーションに複数の Devise モデル ( や など

User
)
Admin
がある場合、Devise がすべてのモデルに同じビューを使用していることに気付くでしょう。幸いなことに、Devise はビューをカスタマイズする簡単な方法を提供します。ファイル
config.scoped_views = true
内で設定するだけです。
config/initializers/devise.rb

そうすると、

users/sessions/new
やのような役割に基づいたビューを持つことができます
admins/sessions/new
。スコープ内にビューが見つからない場合、Devise はデフォルトのビュー at を使用します
devise/sessions/new
。ジェネレーターを使用してスコープ ビューを生成することもできます。

$ rails generate devise:views users

registerable
およびモジュール用のビューのように、少数のビュー セットのみを生成する場合は、フラグ
confirmable
を使用してモジュールのリストをジェネレーターに渡すことができます。
-v

$ rails generate devise:views -v registrations confirmations

コントローラーの構成

If the customization at the views level is not enough, you can customize each controller by following these steps:

  1. Create your custom controllers using the generator which requires a scope:

    $ rails generate devise:controllers [scope]

    If you specify

    users
    as the scope, controllers will be created in
    app/controllers/users/
    . And the sessions controller will look like this:

    class Users::SessionsController < Devise::SessionsController
      # GET /resource/sign_in
      # def new
      #   super
      # end
      ...
    end

    (Use the -c flag to specify a controller, for example:

    rails generate devise:controllers users -c=sessions
    )

  2. Tell the router to use this controller:

    devise_for :users, controllers: { sessions: 'users/sessions' }
  3. Copy the views from

    devise/sessions
    to
    users/sessions
    . Since the controller was changed, it won't use the default views located in
    devise/sessions
    .

  4. Finally, change or extend the desired controller actions.

    You can completely override a controller action:

    class Users::SessionsController < Devise::SessionsController
      def create
        # custom sign-in code
      end
    end

    Or you can simply add new behavior to it:

    class Users::SessionsController < Devise::SessionsController
      def create
        super do |resource|
          BackgroundWorker.trigger(resource)
        end
      end
    end

    This is useful for triggering background jobs or logging events during certain actions.

Remember that Devise uses flash messages to let users know if sign in was successful or unsuccessful. Devise expects your application to call

flash[:notice]
and
flash[:alert]
as appropriate. Do not print the entire flash hash, print only specific keys. In some circumstances, Devise adds a
:timedout
key to the flash hash, which is not meant for display. Remove this key from the hash if you intend to print the entire hash.

Configuring routes

Devise also ships with default routes. If you need to customize them, you should probably be able to do it through the devise_for method. It accepts several options like :class_name, :path_prefix and so on, including the possibility to change path names for 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' }

Be sure to check

devise_for
documentation for details.

If you have the need for more deep customization, for instance to also allow "/sign_in" besides "/users/sign_in", all you need to do is create your routes normally and wrap them in a

devise_scope
block in the router:

devise_scope :user do
  get 'sign_in', to: 'devise/sessions#new'
end

This way, you tell Devise to use the scope

:user
when "/sign_in" is accessed. Notice
devise_scope
is also aliased as
as
in your router.

Please note: You will still need to add

devise_for
in your routes in order to use helper methods such as
current_user
.

devise_for :users, skip: :all

I18n

Devise uses flash messages with I18n, in conjunction with the flash keys :notice and :alert. To customize your app, you can set up your locale file:

en:
  devise:
    sessions:
      signed_in: 'Signed in successfully.'

You can also create distinct messages based on the resource you've configured using the singular name given in routes:

en:
  devise:
    sessions:
      user:
        signed_in: 'Welcome user, you are signed in.'
      admin:
        signed_in: 'Hello admin!'

The Devise mailer uses a similar pattern to create subject messages:

en:
  devise:
    mailer:
      confirmation_instructions:
        subject: 'Hello everybody!'
        user_subject: 'Hello User! Please confirm your email'
      reset_password_instructions:
        subject: 'Reset instructions'

Take a look at our locale file to check all available messages. You may also be interested in one of the many translations that are available on our wiki:

https://github.com/heartcombo/devise/wiki/I18n

Caution: Devise Controllers inherit from ApplicationController. If your app uses multiple locales, you should be sure to set I18n.locale in ApplicationController.

Test helpers

Devise includes some test helpers for controller and integration tests. In order to use them, you need to include the respective module in your test cases/specs.

Controller tests

Controller tests require that you include

Devise::Test::IntegrationHelpers
on your test case or its parent
ActionController::TestCase
superclass. For Rails versions prior to 5, include
Devise::Test::ControllerHelpers
instead, since the superclass for controller tests was changed to ActionDispatch::IntegrationTest (for more details, see the Integration tests section).

class PostsControllerTest < ActionController::TestCase
  include Devise::Test::IntegrationHelpers # Rails >= 5
end
class PostsControllerTest < ActionController::TestCase
  include Devise::Test::ControllerHelpers # Rails < 5
end

If you're using RSpec, you can put the following inside a file named

spec/support/devise.rb
or in your
spec/spec_helper.rb
(or
spec/rails_helper.rb
if you are using
rspec-rails
):

RSpec.configure do |config|
  config.include Devise::Test::ControllerHelpers, type: :controller
  config.include Devise::Test::ControllerHelpers, type: :view
end

Just be sure that this inclusion is made after the

require 'rspec/rails'
directive.

Now you are ready to use the

sign_in
and
sign_out
methods on your controller tests:

sign_in @user
sign_in @user, scope: :admin

Deviseの内部コントローラーまたは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
コントローラー テストとは異なり、テストで実行されるルートによってマッピングを推測できるため、統合テストでは値を指定する必要はありません 。

Rails 3 - Rails 4 コントローラーを RSpec でテストする方法については、wiki で詳しく読むことができます。

OmniAuth

Devise には、すぐに使用できる OmniAuth サポートが付属しており、他のプロバイダーで認証を行うことができます。これを使用するには、OmniAuth 構成を で指定するだけです

config/initializers/devise.rb

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 を使用して、役割ベースのアプローチを使用することをお勧めします。

アクティブジョブの統合

Rails 4.2 と ActiveJob を使用して、キューイング バックエンドを介してバックグラウンドで ActionMailer メッセージを配信している場合

send_devise_notification
、モデルのメソッドをオーバーライドすることで、既存のキューを介して Devise メールを送信できます。

def send_devise_notification(notification, *args)
  devise_mailer.send(notification, self, *args).deliver_later
end

パスワード リセット トークンと Rails ログ

If you enable the Recoverable module, note that a stolen password reset token could give an attacker access to your application. Devise takes effort to generate random, secure tokens, and stores only token digests in the database, never plaintext. However the default logging behavior in Rails can cause plaintext tokens to leak into log files:

  1. Action Mailer logs the entire contents of all outgoing emails to the DEBUG level. Password reset tokens delivered to users in email will be leaked.
  2. Active Job logs all arguments to every enqueued job at the INFO level. If you configure Devise to use
    deliver_later
    to send password reset emails, password reset tokens will be leaked.

Rails は、デフォルトでプロダクション ロガー レベルを INFO に設定します。トークンがログに漏れるのを防ぎたい場合は、本番ロガー レベルを WARN に変更することを検討してください。で

config/environments/production.rb

config.log_level = :warn

その他の ORM

Devise は ActiveRecord (デフォルト) と Mongoid をサポートしています。別の ORM を選択するには、イニシャライザ ファイルでそれを必要とするだけです。

Rails API モード

Rails 5+ には、Rails を API (のみ) として使用するために最適化するAPI モードが組み込まれています。Devise は、例外などを発生させないという意味で、このモードでビルドされたアプリケーションを追加の変更なしで処理することができますただし、この互換性の完全な範囲はまだわかっていないため、

development
/の実行中にいくつかの問題が発生する可能性があります。
testing
(詳細については、問題 #4947を参照してください)

サポートされている認証方法

API のみのアプリケーションは、devise のデフォルトである Cookie を介したブラウザベースの認証をサポートしていません。それでも、devise は、

http_authenticatable
HTTP Basic Auth を使用し、リクエストごとにユーザーを認証する戦略を使用して、これらのケースですぐに使用できる認証を提供できます。(詳細については、How To: Use HTTP Basic Authenticationに関するこの wiki 記事を参照してください)

HTTP Auth のデバイスのデフォルトは無効になっているため、データベース戦略のデバイス初期化子で有効にする必要があります。

config.http_authenticatable = [:database]

この制限は、アプリケーションで、またはデバイス用の gem ベースの拡張機能を介して、カスタムの warden 戦略を実装することを制限しません。API の一般的な認証戦略は、トークン ベースの認証です。このタイプの認証やその他の認証をサポートするようにデバイスを拡張する方法の詳細については、Simple Token Authentication Examples and alternativesに関する wiki 記事、またはDevise を使用したカスタム認証方法に関するこのブログ投稿を参照してください。

テスト

API モードはミドルウェア スタックの順序を変更するため、

Devise::Test::IntegrationHelpers
. この問題は通常
undefined method `[]=' for nil:NilClass
、 などの統合テスト ヘルパーを使用するときにエラーとして表示され
#sign_in
ます。解決策は、次を test.rb に追加して、ミドルウェアの順序を変更するだけです。

Rails.application.config.middleware.insert_before Warden::Manager, ActionDispatch::Cookies
Rails.application.config.middleware.insert_before Warden::Manager, ActionDispatch::Session::CookieStore

これをより深く理解するには、この問題を確認してください。

さらに、ビューがサポートされていないため、確認可能、回復可能、およびロック可能からの一部の電子メールベースのフローは、現時点では直接サポートされていないことに注意してください。

追加情報

ワーデン

Devise は、Daniel Neighman によって作成された一般的な Rack 認証フレームワークである Warden に基づいています。Warden の詳細については、こちらをご覧ください。

https://github.com/wardencommunity/warden

寄稿者

貴重な貢献者の長いリストがあります。それらをすべてチェックしてください:

https://github.com/heartcombo/devise/graphs/contributors

ライセンス

MIT ライセンス。Copyright 2020 Rafael Franca, Leonardo Tegon, Carlos Antônio da Silva. Copyright 2009-2019 Plataformatec.

Devise のロゴは、Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License の下でライセンスされています。