devise
v4.9.4
Rancangan adalah solusi otentikasi fleksibel untuk Rails berdasarkan Warden. Dia:
Ini terdiri dari 10 modul:
Wiki Rancangan memiliki banyak informasi tambahan tentang Rancangan termasuk banyak artikel "cara melakukan" dan jawaban atas pertanyaan yang paling sering diajukan. Silakan telusuri Wiki setelah menyelesaikan README ini:
https://github.com/heartcombo/devise/wiki
Jika Anda menemukan masalah dengan Rancangan, kami ingin mengetahuinya. Namun, kami meminta Anda meninjau pedoman ini sebelum mengirimkan laporan bug:
https://github.com/heartcombo/devise/wiki/Bug-reports
Jika Anda menemukan bug terkait keamanan, JANGAN gunakan pelacak masalah GitHub. Kirim email ke [email protected].
Jika Anda memiliki pertanyaan, komentar, atau kekhawatiran, silakan gunakan StackOverflow alih-alih pelacak masalah GitHub:
http://stackoverflow.com/questions/tagged/devise
Milis yang tidak digunakan lagi masih dapat dibaca
https://groups.google.com/group/plataformatec-devise
Anda dapat melihat dokumentasi Rancangan dalam format RDoc di sini:
http://rubydoc.info/github/heartcombo/devise/main/frames
Jika Anda perlu menggunakan Rancangan dengan versi Rails sebelumnya, Anda selalu dapat menjalankan "server permata" dari baris perintah setelah Anda menginstal permata untuk mengakses dokumentasi lama.
Ada beberapa contoh aplikasi yang tersedia di GitHub yang mendemonstrasikan berbagai fitur Rancangan dengan versi Rails yang berbeda. Anda dapat melihatnya di sini:
https://github.com/heartcombo/devise/wiki/Example-Applications
Komunitas kami telah membuat sejumlah ekstensi yang menambahkan fungsionalitas melebihi apa yang disertakan dengan Rancangan. Anda dapat melihat daftar ekstensi yang tersedia dan menambahkan ekstensi Anda sendiri di sini:
https://github.com/heartcombo/devise/wiki/Extensions
Kami harap Anda mempertimbangkan untuk berkontribusi pada Rancangan. Silakan baca ikhtisar singkat ini untuk mengetahui beberapa informasi tentang cara memulai:
https://github.com/heartcombo/devise/wiki/Contributing
Anda biasanya ingin menulis tes untuk perubahan Anda. Untuk menjalankan rangkaian pengujian, masuk ke direktori tingkat atas Rancangan dan jalankan bundle install dan bin/test . Rancangan berfungsi dengan beberapa versi Ruby dan Rails, serta ActiveRecord dan Mongoid ORM, yang berarti Anda dapat menjalankan rangkaian pengujian dengan beberapa pengubah: DEVISE_ORM dan BUNDLE_GEMFILE .
Karena Rancangan mendukung Mongoid dan ActiveRecord, kami mengandalkan variabel ini untuk menjalankan kode spesifik untuk setiap ORM. Nilai default DEVISE_ORM adalah active_record . Untuk menjalankan pengujian Mongoid, Anda dapat meneruskan mongoid :
DEVISE_ORM=mongoid bin/test
==> Devise.orm = :mongoid
Saat menjalankan pengujian untuk Mongoid, Anda harus memiliki server MongoDB (versi 2.0 atau lebih baru) yang berjalan di sistem Anda.
Harap dicatat bahwa output perintah akan menunjukkan nilai variabel yang digunakan.
Kita dapat menggunakan variabel ini untuk memberi tahu bundler Gemfile apa yang harus digunakan (bukan yang ada di direktori saat ini). Di dalam direktori gemfiles, kami memiliki satu untuk setiap versi Rails yang kami dukung. Saat Anda mengirimkan permintaan penarikan kepada kami, mungkin saja rangkaian pengujian rusak saat menggunakan beberapa di antaranya. Jika demikian, Anda dapat menyimulasikan lingkungan yang sama menggunakan variabel BUNDLE_GEMFILE . Misalnya, jika pengujian gagal menggunakan Ruby 3.0.0 dan Rails 6.0, Anda dapat melakukan hal berikut:
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/testAnda juga dapat menggabungkan keduanya jika tes untuk Mongoid gagal:
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 DEVISE_ORM=mongoid bin/testRancangan menggunakan Mini Test sebagai kerangka pengujian.
bin/testbin/test test/models/trackable_test.rbbin/test test/models/trackable_test.rb:16Jika Anda sedang membangun aplikasi Rails pertama Anda, kami menyarankan Anda untuk tidak menggunakan Rancangan. Rancangan membutuhkan pemahaman yang baik tentang Rails Framework. Dalam kasus seperti ini, kami menyarankan Anda untuk memulai sistem otentikasi sederhana dari awal. Berikut beberapa sumber daya yang dapat membantu Anda memulai:
Setelah Anda memantapkan pemahaman Anda tentang Rails dan mekanisme otentikasi, kami jamin Rancangan akan sangat menyenangkan untuk digunakan. ?
Rancangan 4.0 berfungsi dengan Rails 6.0 dan seterusnya. Berlari:
bundle add deviseSelanjutnya, Anda perlu menjalankan generator:
rails generate devise:install Pada titik ini, sejumlah instruksi akan muncul di konsol. Di antara petunjuk ini, Anda harus menyiapkan opsi URL default untuk mailer Rancangan di setiap lingkungan. Berikut ini kemungkinan konfigurasi untuk config/environments/development.rb :
config . action_mailer . default_url_options = { host : 'localhost' , port : 3000 }Generator akan menginstal inisialisasi yang menjelaskan SEMUA opsi konfigurasi Rancangan. Sangat penting bagi Anda untuk melihatnya. Setelah selesai, Anda siap menambahkan Rancangan ke model mana pun menggunakan generator.
Pada perintah berikut Anda akan mengganti MODEL dengan nama kelas yang digunakan untuk pengguna aplikasi (seringnya User tetapi bisa juga Admin ). Ini akan membuat model (jika tidak ada) dan mengkonfigurasinya dengan modul Rancangan default. Generator juga mengonfigurasi file config/routes.rb Anda agar mengarah ke pengontrol Rancangan.
rails generate devise MODELSelanjutnya, periksa MODEL untuk opsi konfigurasi tambahan apa pun yang mungkin ingin Anda tambahkan, seperti dapat dikonfirmasi atau dapat dikunci. Jika Anda menambahkan opsi, pastikan untuk memeriksa file migrasi (dibuat oleh generator jika ORM Anda mendukungnya) dan hapus komentar pada bagian yang sesuai. Misalnya, jika Anda menambahkan opsi yang dapat dikonfirmasi dalam model, Anda harus menghapus komentar pada bagian yang Dapat Dikonfirmasi dalam migrasi.
Kemudian jalankan rails db:migrate
Anda harus memulai ulang aplikasi Anda setelah mengubah opsi konfigurasi Rancangan (ini termasuk menghentikan pegas). Jika tidak, Anda akan mengalami kesalahan aneh, misalnya, pengguna tidak dapat masuk dan pembantu rute tidak ditentukan.
Rancangan akan membuat beberapa pembantu untuk digunakan di dalam pengontrol dan tampilan Anda. Untuk menyiapkan pengontrol dengan otentikasi pengguna, cukup tambahkan before_action ini (dengan asumsi model rancangan Anda adalah 'Pengguna'):
before_action :authenticate_user! Untuk Rails 5, perhatikan bahwa protect_from_forgery tidak lagi ditambahkan ke rantai before_action , jadi jika Anda telah menyetel authenticate_user sebelum protect_from_forgery , permintaan Anda akan menghasilkan "Tidak dapat memverifikasi keaslian token CSRF." Untuk mengatasinya, ubah urutan pemanggilan Anda, atau gunakan protect_from_forgery prepend: true .
Jika model rancangan Anda selain Pengguna, ganti "_pengguna" dengan "_modelAnda". Logika yang sama berlaku untuk petunjuk di bawah ini.
Untuk memverifikasi apakah pengguna sudah masuk, gunakan bantuan berikut:
user_signed_in?Untuk pengguna yang masuk saat ini, bantuan ini tersedia:
current_userAnda dapat mengakses sesi untuk cakupan ini:
user_session Setelah pengguna masuk, mengonfirmasi akun, atau memperbarui kata sandi, Rancangan akan mencari jalur root tercakup untuk dialihkan. Misalnya, saat menggunakan sumber daya :user , user_root_path akan digunakan jika ada; jika tidak, root_path default akan digunakan. Ini berarti Anda perlu menyetel root di dalam rute Anda:
root to : 'home#index' Anda juga dapat mengganti after_sign_in_path_for dan after_sign_out_path_for untuk menyesuaikan kait pengalihan Anda.
Perhatikan bahwa jika model Rancangan Anda disebut Member dan bukan User , misalnya, maka pembantu yang tersedia adalah:
before_action :authenticate_member!
member_signed_in?
current_member
member_sessionMetode Rancangan dalam model Anda juga menerima beberapa opsi untuk mengonfigurasi modulnya. Misalnya, Anda dapat memilih biaya algoritma hashing dengan:
devise :database_authenticatable , :registerable , :confirmable , :recoverable , stretches : 13 Selain :stretches , Anda dapat menentukan :pepper , :encryptor , :confirm_within , :remember_for , :timeout_in , :unlock_in di antara opsi lainnya. Untuk lebih jelasnya, lihat file penginisialisasi yang dibuat saat Anda menjalankan generator "devise:install" yang dijelaskan di atas. File ini biasanya terletak di /config/initializers/devise.rb .
Parameter Sanitizer API telah berubah untuk Rancangan 4
Untuk versi Rancangan sebelumnya lihat https://github.com/heartcombo/devise/tree/3-stable#strong-parameters
Saat Anda mengkustomisasi tampilan Anda sendiri, Anda mungkin akan menambahkan atribut baru ke formulir. Rails 4 memindahkan parameter sanitasi dari model ke pengontrol, menyebabkan Rancangan menangani masalah ini di pengontrol juga.
Hanya ada tiga tindakan di Rancangan yang memungkinkan serangkaian parameter diteruskan ke model, sehingga memerlukan sanitasi. Nama dan parameter default yang diizinkan adalah:
sign_in ( Devise::SessionsController#create ) - Hanya mengizinkan kunci autentikasi (seperti email )sign_up ( Devise::RegistrationsController#create ) - Mengizinkan kunci autentikasi ditambah password dan password_confirmationaccount_update ( Devise::RegistrationsController#update ) - Mengizinkan kunci autentikasi ditambah password , password_confirmation , dan current_password Jika Anda ingin mengizinkan parameter tambahan (cara malas™), Anda dapat melakukannya menggunakan tindakan sederhana sebelum di ApplicationController Anda :
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 Cara di atas berfungsi untuk bidang tambahan apa pun yang parameternya adalah tipe skalar sederhana. Jika Anda memiliki atribut bersarang (misalkan Anda menggunakan accepts_nested_attributes_for ), maka Anda perlu memberi tahu rancangan tentang sarang dan tipe tersebut:
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
endRancangan memungkinkan Anda untuk sepenuhnya mengubah default Rancangan atau menjalankan perilaku khusus dengan meneruskan satu blok:
Untuk mengizinkan nilai skalar sederhana untuk nama pengguna dan email, gunakan ini
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_in ) do | user_params |
user_params . permit ( :username , :email )
end
endJika Anda memiliki beberapa kotak centang yang menyatakan peran yang mungkin diambil pengguna saat registrasi, browser akan mengirimkan kotak centang yang dipilih tersebut sebagai array. Array bukan salah satu skalar Parameter Kuat yang diizinkan, jadi kita perlu mengonfigurasi Rancangan dengan cara berikut:
def configure_permitted_parameters
devise_parameter_sanitizer . permit ( :sign_up ) do | user_params |
user_params . permit ( { roles : [ ] } , :email , :password , :password_confirmation )
end
endUntuk daftar skalar yang diizinkan, dan cara mendeklarasikan kunci yang diizinkan dalam hash dan array bersarang, lihat
https://github.com/rails/strong_parameters#nested-parameters
Jika Anda memiliki beberapa model Rancangan, Anda mungkin ingin menyiapkan pembersih parameter yang berbeda untuk setiap model. Dalam hal ini, kami menyarankan untuk mewarisi dari Devise::ParameterSanitizer dan menambahkan logika Anda sendiri:
class User :: ParameterSanitizer < Devise :: ParameterSanitizer
def initialize ( * )
super
permit ( :sign_up , keys : [ :username , :email ] )
end
endDan kemudian konfigurasikan pengontrol Anda untuk menggunakannya:
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 Contoh di atas mengesampingkan parameter yang diizinkan bagi pengguna menjadi :username dan :email . Cara yang tidak malas untuk mengonfigurasi parameter adalah dengan mendefinisikan filter sebelum di atas dalam pengontrol khusus. Kami merinci cara mengonfigurasi dan menyesuaikan pengontrol di beberapa bagian di bawah.
Kami membuat Rancangan untuk membantu Anda dengan cepat mengembangkan aplikasi yang menggunakan otentikasi. Namun, kami tidak ingin menghalangi Anda saat Anda perlu menyesuaikannya.
Karena Rancangan adalah sebuah mesin, semua tampilannya dikemas di dalam permata. Pandangan ini akan membantu Anda memulai, namun setelah beberapa waktu Anda mungkin ingin mengubahnya. Jika hal ini terjadi, Anda hanya perlu menjalankan generator berikut, dan generator tersebut akan menyalin semua tampilan ke aplikasi Anda:
rails generate devise:views Jika Anda memiliki lebih dari satu model Rancangan dalam aplikasi Anda (seperti User dan Admin ), Anda akan melihat bahwa Rancangan menggunakan tampilan yang sama untuk semua model. Untungnya, Rancangan menawarkan cara mudah untuk menyesuaikan tampilan. Yang perlu Anda lakukan hanyalah mengatur config.scoped_views = true di dalam file config/initializers/devise.rb .
Setelah melakukannya, Anda akan dapat memiliki tampilan berdasarkan peran seperti users/sessions/new dan admins/sessions/new . Jika tidak ada tampilan yang ditemukan dalam cakupan, Rancangan akan menggunakan tampilan default di devise/sessions/new . Anda juga dapat menggunakan generator untuk menghasilkan tampilan tercakup:
rails generate devise:views users Jika Anda hanya ingin menghasilkan beberapa set tampilan, seperti modul registerable dan confirmable , Anda dapat meneruskan daftar tampilan ke generator dengan flag -v .
rails generate devise:views -v registrations confirmationsJika penyesuaian pada tingkat tampilan tidak cukup, Anda dapat menyesuaikan setiap pengontrol dengan mengikuti langkah-langkah berikut:
Buat pengontrol khusus Anda menggunakan generator yang memerlukan cakupan:
rails generate devise:controllers [scope] Jika Anda menentukan users sebagai cakupannya, pengontrol akan dibuat di app/controllers/users/ . Dan pengontrol sesi akan terlihat seperti ini:
class Users :: SessionsController < Devise :: SessionsController
# GET /resource/sign_in
# def new
# super
# end
...
end Gunakan flag -c untuk menentukan satu atau lebih pengontrol, misalnya: rails generate devise:controllers users -c sessions
Beri tahu router untuk menggunakan pengontrol ini:
devise_for :users , controllers : { sessions : 'users/sessions' } Direkomendasikan tetapi tidak wajib: salin (atau pindahkan) tampilan dari devise/sessions ke users/sessions . Rails akan terus menggunakan tampilan dari devise/sessions karena pewarisan jika Anda melewatkan langkah ini, tetapi memiliki tampilan yang cocok dengan pengontrol akan menjaga semuanya tetap konsisten.
Terakhir, ubah atau perluas tindakan pengontrol yang diinginkan.
Anda dapat sepenuhnya mengganti tindakan pengontrol:
class Users :: SessionsController < Devise :: SessionsController
def create
# custom sign-in code
end
endAtau Anda cukup menambahkan perilaku baru ke dalamnya:
class Users :: SessionsController < Devise :: SessionsController
def create
super do | resource |
BackgroundWorker . trigger ( resource )
end
end
endHal ini berguna untuk memicu pekerjaan latar belakang atau mencatat peristiwa selama tindakan tertentu.
Ingatlah bahwa Rancangan menggunakan pesan flash untuk memberi tahu pengguna apakah proses masuk berhasil atau gagal. Rancangan mengharapkan aplikasi Anda memanggil flash[:notice] dan flash[:alert] sebagaimana mestinya. Jangan cetak seluruh hash flash, cetak hanya kunci tertentu. Dalam beberapa keadaan, Rancangan menambahkan kunci :timedout ke hash flash, yang tidak dimaksudkan untuk ditampilkan. Hapus kunci ini dari hash jika Anda ingin mencetak seluruh hash.
Rancangan juga dikirimkan dengan rute default. Jika Anda perlu menyesuaikannya, Anda mungkin dapat melakukannya melalui metode devise_for. Ia menerima beberapa opsi seperti :class_name, :path_prefix dan seterusnya, termasuk kemungkinan untuk mengubah nama jalur untuk 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' } Pastikan untuk memeriksa dokumentasi devise_for untuk detailnya.
Jika Anda memerlukan penyesuaian yang lebih mendalam, misalnya mengizinkan "/sign_in" selain "/users/sign_in", yang perlu Anda lakukan hanyalah membuat rute secara normal dan membungkusnya dalam blok devise_scope di router:
devise_scope :user do
get 'sign_in' , to : 'devise/sessions#new'
end Dengan cara ini, Anda memberi tahu Rancangan untuk menggunakan cakupan :user ketika "/sign_in" diakses. Perhatikan devise_scope juga alias as di router Anda.
Harap dicatat: Anda masih perlu menambahkan devise_for di rute Anda untuk menggunakan metode pembantu seperti current_user .
devise_for :users , skip : :allRancangan terintegrasi dengan Hotwire/Turbo dengan memperlakukan permintaan tersebut sebagai navigasi, dan mengonfigurasi respons tertentu untuk kesalahan dan pengalihan agar sesuai dengan perilaku yang diharapkan. Aplikasi baru dibuat dengan konfigurasi respons berikut secara default, dan aplikasi yang sudah ada dapat ikut serta dengan menambahkan konfigurasi ke inisialisasi Rancangannya:
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 Penting : tanggapan khusus ini memerlukan versi permata responders 3.1.0 atau lebih tinggi, pastikan Anda memperbaruinya jika Anda akan menggunakan konfigurasi ini. Periksa panduan peningkatan ini untuk info lebih lanjut.
Catatan : konfigurasi status di atas mungkin menjadi default untuk Rancangan di rilis mendatang.
Ada beberapa perubahan lain yang mungkin perlu Anda lakukan di aplikasi agar dapat berfungsi dengan Hotwire/Turbo, jika Anda bermigrasi dari rails-ujs:
data-confirm yang menambahkan modal konfirmasi ke tombol/formulir sebelum pengiriman perlu diubah menjadi data-turbo-confirm , sehingga Turbo menanganinya dengan tepat.data-method yang menetapkan metode permintaan untuk pengiriman tautan perlu diubah menjadi data-turbo-method . Ini tidak diperlukan untuk button_to atau form s karena Turbo dapat mengatasinya. Jika Anda menyiapkan Rancangan untuk keluar melalui :delete , dan Anda menggunakan tautan (bukan tombol yang disertakan dalam formulir) untuk keluar dengan method: :delete , tautan tersebut perlu diperbarui seperti dijelaskan di atas. (Rancangan tidak menyediakan tautan/tombol keluar dalam tampilan yang dibagikan.)
Pastikan untuk memeriksa pandangan Anda untuk mencarinya, dan ubah dengan tepat.
Rancangan menggunakan pesan flash dengan I18n, bersama dengan tombol flash :notice dan :alert. Untuk menyesuaikan aplikasi, Anda dapat menyiapkan file lokal:
en :
devise :
sessions :
signed_in : ' Signed in successfully. 'Anda juga dapat membuat pesan berbeda berdasarkan sumber daya yang telah Anda konfigurasikan menggunakan nama tunggal yang diberikan dalam rute:
en :
devise :
sessions :
user :
signed_in : ' Welcome user, you are signed in. '
admin :
signed_in : ' Hello admin! 'Mailer Rancangan menggunakan pola serupa untuk membuat pesan subjek:
en :
devise :
mailer :
confirmation_instructions :
subject : ' Hello everybody! '
user_subject : ' Hello User! Please confirm your email '
reset_password_instructions :
subject : ' Reset instructions 'Lihatlah file lokal kami untuk memeriksa semua pesan yang tersedia. Anda mungkin juga tertarik dengan salah satu dari banyak terjemahan yang tersedia di wiki kami:
https://github.com/heartcombo/devise/wiki/I18n
Perhatian: Rancangan Pengendali yang diwarisi dari ApplicationController. Jika aplikasi Anda menggunakan beberapa lokal, Anda harus memastikan untuk menyetel I18n.locale di ApplicationController.
Rancangan mencakup beberapa pembantu pengujian untuk pengujian pengontrol dan integrasi. Untuk menggunakannya, Anda perlu menyertakan modul terkait dalam kasus pengujian/spesifikasi Anda.
Pengujian pengontrol mengharuskan Anda menyertakan Devise::Test::IntegrationHelpers pada kasus pengujian Anda atau superkelas ActionController::TestCase induknya. Untuk versi Rails sebelum 5, sertakan Devise::Test::ControllerHelpers sebagai gantinya, karena superclass untuk pengujian pengontrol diubah menjadi ActionDispatch::IntegrationTest (untuk detail selengkapnya, lihat bagian Pengujian integrasi).
class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: IntegrationHelpers # Rails >= 5
end class PostsControllerTest < ActionController :: TestCase
include Devise :: Test :: ControllerHelpers # Rails < 5
end Jika Anda menggunakan RSpec, Anda dapat memasukkan yang berikut ini ke dalam file bernama spec/support/devise.rb atau di spec/spec_helper.rb Anda (atau spec/rails_helper.rb jika Anda menggunakan rspec-rails ):
RSpec . configure do | config |
config . include Devise :: Test :: ControllerHelpers , type : :controller
config . include Devise :: Test :: ControllerHelpers , type : :view
end Pastikan penyertaan ini dilakukan setelah arahan require 'rspec/rails' .
Sekarang Anda siap menggunakan metode sign_in dan sign_out pada pengujian pengontrol Anda:
sign_in @user
sign_in @user , scope : :adminJika Anda menguji pengontrol internal Rancangan atau pengontrol yang mewarisi dari Rancangan, Anda perlu memberi tahu Rancangan pemetaan mana yang harus digunakan sebelum permintaan. Hal ini diperlukan karena Rancangan mendapatkan informasi ini dari router, tetapi karena pengujian pengontrol tidak melewati router, maka perlu dinyatakan secara eksplisit. Misalnya, jika Anda menguji cakupan pengguna, cukup gunakan:
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 Pembantu pengujian integrasi tersedia dengan menyertakan modul Devise::Test::IntegrationHelpers .
class PostsTests < ActionDispatch :: IntegrationTest
include Devise :: Test :: IntegrationHelpers
end Sekarang Anda dapat menggunakan metode sign_in dan sign_out berikut dalam pengujian integrasi Anda:
sign_in users ( :bob )
sign_in users ( :bob ) , scope : :admin
sign_out :user Pengguna RSpec dapat menyertakan modul IntegrationHelpers pada spesifikasi :feature mereka.
RSpec . configure do | config |
config . include Devise :: Test :: IntegrationHelpers , type : :feature
end Berbeda dengan pengujian pengontrol, pengujian integrasi tidak perlu memberikan nilai devise.mapping env , karena pemetaan dapat disimpulkan dari rute yang dijalankan dalam pengujian Anda.
Anda dapat membaca lebih lanjut tentang pengujian pengontrol Rails Anda dengan RSpec di wiki:
Rancangan hadir dengan dukungan OmniAuth siap pakai untuk mengautentikasi dengan penyedia lain. Untuk menggunakannya, cukup tentukan konfigurasi OmniAuth Anda di config/initializers/devise.rb :
config . omniauth :github , 'APP_ID' , 'APP_SECRET' , scope : 'user,public_repo'Anda dapat membaca lebih lanjut tentang dukungan OmniAuth di wiki:
Rancangan memungkinkan Anda mengatur model Rancangan sebanyak yang Anda inginkan. Jika Anda ingin memiliki model Admin dengan fitur autentikasi dan timeout saja, selain model User di atas, jalankan saja:
# 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_sessionAlternatifnya, Anda cukup menjalankan generator Rancangan.
Ingatlah bahwa model tersebut akan memiliki rute yang sangat berbeda. Mereka tidak dan tidak dapat berbagi pengontrol yang sama untuk masuk, keluar, dan sebagainya. Jika Anda ingin memiliki peran berbeda yang berbagi tindakan yang sama, kami menyarankan Anda menggunakan pendekatan berbasis peran, dengan menyediakan kolom peran atau menggunakan permata khusus untuk otorisasi.
Jika Anda menggunakan Pekerjaan Aktif untuk mengirimkan pesan Action Mailer di latar belakang melalui antrian back-end, Anda dapat mengirim email Rancangan melalui antrian yang ada dengan mengganti metode send_devise_notification dalam model Anda.
def send_devise_notification ( notification , * args )
devise_mailer . send ( notification , self , * args ) . deliver_later
endJika Anda mengaktifkan modul Dapat Dipulihkan, perhatikan bahwa token pengaturan ulang kata sandi yang dicuri dapat memberikan akses kepada penyerang ke aplikasi Anda. Rancangan membutuhkan upaya untuk menghasilkan token yang acak dan aman, dan hanya menyimpan intisari token dalam database, bukan teks biasa. Namun perilaku logging default di Rails dapat menyebabkan token teks biasa bocor ke file log:
deliver_later untuk mengirim email pengaturan ulang kata sandi, token pengaturan ulang kata sandi akan bocor. Rails menyetel level logger produksi ke INFO secara default. Pertimbangkan untuk mengubah level logger produksi Anda menjadi WARN jika Anda ingin mencegah kebocoran token ke dalam log Anda. Di config/environments/production.rb :
config . log_level = :warnRancangan mendukung ActiveRecord (default) dan Mongoid. Untuk memilih ORM lain, cukup minta ORM tersebut di file penginisialisasi.
Rails 5+ memiliki Mode API bawaan yang mengoptimalkan Rails untuk digunakan sebagai API (hanya). Rancangan agak mampu menangani aplikasi yang dibangun dalam mode ini tanpa modifikasi tambahan dalam artian tidak boleh memunculkan pengecualian dan sejenisnya. Namun beberapa masalah mungkin masih muncul selama development / testing , karena kami masih belum mengetahui sepenuhnya sejauh mana kompatibilitas ini. (Untuk informasi lebih lanjut, lihat edisi #4947)
Aplikasi khusus API tidak mendukung autentikasi berbasis browser melalui cookie, yang merupakan default perangkat. Namun, devise tetap dapat memberikan autentikasi langsung dalam kasus tersebut dengan strategi http_authenticatable , yang menggunakan HTTP Basic Auth dan mengautentikasi pengguna pada setiap permintaan. (Untuk info lebih lanjut, lihat artikel wiki ini untuk Cara: Menggunakan Otentikasi Dasar HTTP)
Default rancangan untuk HTTP Auth dinonaktifkan, sehingga harus diaktifkan di penginisialisasi rancangan untuk strategi database:
config . http_authenticatable = [ :database ]Pembatasan ini tidak membatasi Anda untuk menerapkan strategi sipir khusus, baik dalam aplikasi Anda atau melalui ekstensi berbasis permata untuk dirancang. Strategi autentikasi umum untuk API adalah autentikasi berbasis token. Untuk informasi lebih lanjut tentang memperluas perangkat untuk mendukung jenis otentikasi ini dan lainnya, lihat artikel wiki untuk Contoh dan Alternatif Otentikasi Token Sederhana atau posting blog ini tentang Metode otentikasi khusus dengan Rancangan.
Mode API mengubah urutan tumpukan middleware, dan ini dapat menyebabkan masalah untuk Devise::Test::IntegrationHelpers . Masalah ini biasanya muncul sebagai undefined method `[]=' for nil:NilClass saat menggunakan pembantu pengujian integrasi, seperti #sign_in . Solusinya adalah dengan menyusun ulang middleware dengan menambahkan yang berikut ke test.rb:
Rails . application
