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
여기에서 RDoc 형식의 Devise 문서를 볼 수 있습니다.
http://rubydoc.info/github/heartcombo/devise/main/frames
이전 버전의 Rails에서 Devise를 사용해야 하는 경우, gem을 설치한 후 언제든지 명령줄에서 "gem server"를 실행하여 이전 문서에 액세스할 수 있습니다.
다양한 버전의 Rails를 사용하여 Devise의 다양한 기능을 보여주는 몇 가지 예제 애플리케이션이 GitHub에 있습니다. 여기에서 볼 수 있습니다:
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 버전별로 하나씩 있습니다. 우리에게 풀 리퀘스트를 보낼 때, 그 중 일부를 사용하면 테스트 스위트가 중단되는 일이 발생할 수 있습니다. 이 경우 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다음으로 확인 가능 또는 잠금 가능 등 추가할 추가 구성 옵션이 있는지 MODEL을 확인하세요. 옵션을 추가하는 경우 마이그레이션 파일(ORM이 지원하는 경우 생성기에 의해 생성됨)을 검사하고 해당 섹션의 주석 처리를 제거하십시오. 예를 들어 모델에 확인 가능 옵션을 추가하는 경우 마이그레이션에서 확인 가능 섹션의 주석 처리를 제거해야 합니다.
그런 다음 rails db:migrate 실행하세요.
Devise의 구성 옵션을 변경한 후에는 애플리케이션을 다시 시작해야 합니다(여기에는 스프링 중지도 포함됩니다). 그렇지 않으면 사용자가 로그인할 수 없고 라우트 도우미가 정의되지 않는 등 이상한 오류가 발생합니다.
Devise는 컨트롤러와 뷰 내부에서 사용할 몇 가지 도우미를 만듭니다. 사용자 인증을 사용하여 컨트롤러를 설정하려면 다음 before_action을 추가하면 됩니다(디바이스 모델이 'User'라고 가정).
before_action :authenticate_user! Rails 5의 경우, protect_from_forgery 더 이상 before_action 체인 앞에 추가되지 않습니다. 따라서 protect_from_forgery 전에 authenticate_user 설정한 경우 요청 결과는 "CSRF 토큰 신뢰성을 확인할 수 없습니다."입니다. 이 문제를 해결하려면 호출 순서를 변경하거나 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 모델이 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에서는 Parameter Sanitizer API가 변경되었습니다.
이전 Devise 버전은 https://github.com/heartcombo/devise/tree/3-stable#strong-parameters를 참조하세요.
자신만의 보기를 사용자 정의할 때 양식에 새로운 속성을 추가하게 될 수도 있습니다. Rails 4에서는 매개변수 삭제를 모델에서 컨트롤러로 이동하여 Devise가 컨트롤러에서도 이 문제를 처리하도록 했습니다.
Devise에는 모든 매개변수 세트를 모델에 전달할 수 있도록 허용하는 세 가지 작업만 있으므로 삭제가 필요합니다. 해당 이름과 기본 허용 매개변수는 다음과 같습니다.
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 사용하고 있음) 해당 중첩 및 유형에 대해 devise에 알려야 합니다.
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 매개변수의 허용된 스칼라 중 하나가 아니므로 다음과 같은 방법으로 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 플래그를 사용하여 하나 이상의 컨트롤러를 지정합니다. 예: 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에는 기본 경로도 함께 제공됩니다. 이를 사용자 정의해야 하는 경우 devise_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 이렇게 하면 Devise가 "/sign_in"에 액세스할 때 :user 범위를 사용하도록 지시할 수 있습니다. 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 로 변경해야 합니다. Turbo가 이를 처리할 수 있으므로 button_to 또는 form s에는 필요하지 않습니다. :delete 통해 로그아웃하도록 Devise를 설정하고 있고, (양식에 싸인 버튼 대신) 링크를 사용하여 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 '사용 가능한 모든 메시지를 확인하려면 로케일 파일을 살펴보세요. 당신은 또한 우리 위키에서 이용할 수 있는 많은 번역 중 하나에 관심이 있을 수도 있습니다:
https://github.com/heartcombo/devise/wiki/I18n
주의: Devise Controller는 ApplicationController에서 상속됩니다. 앱이 여러 로캘을 사용하는 경우 ApplicationController에서 I18n.locale을 설정해야 합니다.
Devise에는 컨트롤러 및 통합 테스트를 위한 일부 테스트 도우미가 포함되어 있습니다. 이를 사용하려면 테스트 사례/사양에 해당 모듈을 포함해야 합니다.
컨트롤러 테스트에서는 Devise::Test::IntegrationHelpers 테스트 케이스 또는 상위 ActionController::TestCase 슈퍼클래스에 포함해야 합니다. 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 사용자는 :feature 사양에 IntegrationHelpers 모듈을 포함할 수 있습니다.
RSpec . configure do | config |
config . include Devise :: Test :: IntegrationHelpers , type : :feature
end 컨트롤러 테스트와 달리 통합 테스트는 devise.mapping env 값을 제공할 필요가 없습니다. 매핑은 테스트에서 실행되는 경로에 의해 추론될 수 있기 때문입니다.
위키에서 RSpec을 사용하여 Rails 컨트롤러를 테스트하는 방법에 대해 자세히 알아볼 수 있습니다.
Devise에는 다른 공급자를 인증할 수 있도록 즉시 OmniAuth 지원이 제공됩니다. 이를 사용하려면 config/initializers/devise.rb 에서 OmniAuth 구성을 지정하기만 하면 됩니다.
config . omniauth :github , 'APP_ID' , 'APP_SECRET' , scope : 'user,public_repo'Wiki에서 OmniAuth 지원에 대해 자세히 알아볼 수 있습니다.
Devise를 사용하면 원하는 만큼 많은 Devise 모델을 설정할 수 있습니다. 위의 User 모델 외에 인증 및 시간 제한 기능만 있는 관리 모델을 원한다면 다음을 실행하세요.
# 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을 사용하여 역할 기반 접근 방식을 사용하는 것이 좋습니다.
대기열 백엔드를 통해 백그라운드에서 Action Mailer 메시지를 전달하기 위해 Active Job을 사용하는 경우 모델의 send_devise_notification 메서드를 재정의하여 기존 대기열을 통해 Devise 이메일을 보낼 수 있습니다.
def send_devise_notification ( notification , * args )
devise_mailer . send ( notification , self , * args ) . deliver_later
end복구 가능 모듈을 활성화하는 경우 도난당한 비밀번호 재설정 토큰으로 인해 공격자가 애플리케이션에 액세스할 수 있다는 점에 유의하세요. Devise는 임의의 안전한 토큰을 생성하기 위해 노력하고 일반 텍스트가 아닌 토큰 다이제스트만 데이터베이스에 저장합니다. 그러나 Rails의 기본 로깅 동작으로 인해 일반 텍스트 토큰이 로그 파일로 유출될 수 있습니다.
deliver_later 사용하여 비밀번호 재설정 이메일을 보내도록 Devise를 구성하면 비밀번호 재설정 토큰이 유출됩니다. Rails는 기본적으로 프로덕션 로거 수준을 INFO로 설정합니다. 토큰이 로그로 유출되는 것을 방지하려면 프로덕션 로거 수준을 WARN으로 변경하는 것이 좋습니다. config/environments/production.rb 에서:
config . log_level = :warnDevise는 ActiveRecord(기본값)와 Mongoid를 지원합니다. 다른 ORM을 선택하려면 초기화 파일에서 이를 요구하면 됩니다.
Rails 5+에는 Rails를 API(전용)로 사용하도록 최적화하는 내장 API 모드가 있습니다. Devise는 예외 등을 발생시키지 않아야 한다는 점에서 추가 수정 없이 이 모드에서 구축된 응용 프로그램을 어느 정도 처리할 수 있습니다. 그러나 우리는 아직 이 호환성의 전체 범위를 알지 못하기 때문에 development / testing 중에 일부 문제가 여전히 발생할 수 있습니다. (자세한 내용은 문제 #4947을 참조하세요.)
API 전용 애플리케이션은 devise의 기본값인 쿠키를 통한 브라우저 기반 인증을 지원하지 않습니다. 그러나 devise는 HTTP 기본 인증을 사용하고 각 요청에서 사용자를 인증하는 http_authenticatable 전략을 사용하여 이러한 경우에도 즉시 인증을 제공할 수 있습니다. (자세한 내용은 방법: HTTP 기본 인증 사용에 대한 위키 문서를 참조하세요.)
HTTP 인증에 대한 devise 기본값은 비활성화되어 있으므로 데이터베이스 전략에 대한 devise 초기화 프로그램에서 활성화해야 합니다.
config . http_authenticatable = [ :database ]이 제한은 애플리케이션이나 고안용 보석 기반 확장을 통해 사용자 정의 소장 전략을 구현하는 것을 제한하지 않습니다. API에 대한 일반적인 인증 전략은 토큰 기반 인증입니다. 이러한 유형의 인증 및 기타 인증을 지원하기 위해 devise를 확장하는 방법에 대한 자세한 내용은 단순 토큰 인증 예제 및 대안에 대한 Wiki 기사 또는 Devise를 사용한 사용자 정의 인증 방법에 대한 이 블로그 게시물을 참조하세요.
API 모드는 미들웨어 스택의 순서를 변경하며 이로 인해 Devise::Test::IntegrationHelpers 에 문제가 발생할 수 있습니다. 이 문제는 일반적으로 #sign_in 과 같은 통합 테스트 헬퍼를 사용할 때 undefined method `[]=' for nil:NilClass 로 나타납니다. 해결책은 test.rb에 다음을 추가하여 미들웨어의 순서를 변경하는 것입니다.
Rails . application
