Devise هو حل مصادقة مرن لـ Rails يعتمد على Warden. هو - هي:
يتكون من 10 وحدات:
يحتوي موقع Devise Wiki على الكثير من المعلومات الإضافية حول Devise بما في ذلك العديد من المقالات "الإرشادية" والإجابات على الأسئلة الأكثر شيوعًا. يرجى تصفح الويكي بعد الانتهاء من هذا الملف التمهيدي:
https://github.com/heartcombo/devise/wiki
إذا اكتشفت مشكلة في Devise، فنحن نود أن نعرف عنها. ومع ذلك، فإننا نطلب منك مراجعة هذه الإرشادات قبل إرسال تقرير بالأخطاء:
https://github.com/heartcombo/devise/wiki/Bug-reports
إذا اكتشفت خطأً متعلقًا بالأمان، فيرجى عدم استخدام أداة تعقب مشكلات GitHub. أرسل بريدًا إلكترونيًا إلى [email protected].
إذا كانت لديك أية أسئلة أو تعليقات أو استفسارات، فيرجى استخدام StackOverflow بدلاً من أداة تعقب مشكلات GitHub:
http://stackoverflow.com/questions/tagged/devise
لا يزال من الممكن قراءة القائمة البريدية المهملة
https://groups.google.com/group/plataformatec-devise
يمكنك عرض وثائق Devise بتنسيق RDoc هنا:
http://rubydoc.info/github/heartcombo/devise/main/frames
إذا كنت بحاجة إلى استخدام Devise مع الإصدارات السابقة من Rails، فيمكنك دائمًا تشغيل "gem server" من سطر الأوامر بعد تثبيت الجوهرة للوصول إلى الوثائق القديمة.
هناك بعض الأمثلة على التطبيقات المتاحة على GitHub والتي توضح ميزات متنوعة لـ Devise مع إصدارات مختلفة من Rails. يمكنك مشاهدتها هنا:
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 وMongid ORMs، مما يعني أنه يمكنك تشغيل مجموعة الاختبار باستخدام بعض المعدلات: 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/test
يمكنك أيضًا الجمع بين كليهما إذا تعطلت اختبارات Mongoid:
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 bundle install
BUNDLE_GEMFILE=gemfiles/Gemfile-rails-6-0 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 الأول، فنوصيك بعدم استخدام Devise. يتطلب Devise فهمًا جيدًا لإطار عمل Rails. في مثل هذه الحالات، ننصحك ببدء نظام مصادقة بسيط من الصفر. إليك بعض الموارد التي من المفترض أن تساعدك على البدء:
بمجرد تعزيز فهمك لـ Rails وآليات المصادقة، نؤكد لك أن العمل مع Devise سيكون ممتعًا للغاية. ؟
يعمل Devise 4.0 مع Rails 6.0 وما بعده. يجري:
bundle add devise
بعد ذلك، تحتاج إلى تشغيل المولد:
rails generate devise:install
عند هذه النقطة، سيظهر عدد من التعليمات في وحدة التحكم. ومن بين هذه الإرشادات، ستحتاج إلى إعداد خيارات URL الافتراضية لجهاز Devise mailer في كل بيئة. فيما يلي تكوين محتمل لـ 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
بعد ذلك، تحقق من MODEL بحثًا عن أي خيارات تكوين إضافية قد ترغب في إضافتها، مثل خيارات التكوين القابلة للتأكيد أو القابلة للقفل. إذا قمت بإضافة خيار، فتأكد من فحص ملف الترحيل (الذي تم إنشاؤه بواسطة المولد إذا كان ORM الخاص بك يدعمه) وقم بإلغاء التعليق على القسم المناسب. على سبيل المثال، إذا قمت بإضافة الخيار القابل للتأكيد في النموذج، فستحتاج إلى إلغاء التعليق على القسم القابل للتأكيد في عملية الترحيل.
ثم قم بتشغيل rails db:migrate
يجب عليك إعادة تشغيل التطبيق الخاص بك بعد تغيير خيارات تكوين Devise (وهذا يشمل إيقاف الربيع). وإلا، فسوف تواجه أخطاء غريبة، على سبيل المثال، عدم قدرة المستخدمين على تسجيل الدخول وعدم تحديد مسار المساعدين.
سيقوم Devise بإنشاء بعض المساعدين لاستخدامها داخل وحدات التحكم وطرق العرض الخاصة بك. لإعداد وحدة تحكم بمصادقة المستخدم، ما عليك سوى إضافة before_action (على افتراض أن نموذج التصميم الخاص بك هو "المستخدم"):
before_action :authenticate_user!
بالنسبة لـ Rails 5، لاحظ أن protect_from_forgery
لم يعد مُلحقًا بسلسلة before_action
، لذلك إذا قمت بتعيين authenticate_user
قبل protect_from_forgery
، فسيؤدي طلبك إلى "لا يمكن التحقق من مصادقة رمز 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 الخاص بك يسمى Member
بدلاً من User
، على سبيل المثال، فإن المساعدين المتاحين هم:
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
من بين الخيارات الأخرى. لمزيد من التفاصيل، راجع ملف التهيئة الذي تم إنشاؤه عندما قمت باستدعاء المولد "device:install" الموضح أعلاه. يوجد هذا الملف عادةً في /config/initializers/devise.rb
.
لقد تغيرت واجهة برمجة تطبيقات Parameter Sanitizer لـ Devise 4
للاطلاع على إصدارات 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
في حالة رغبتك في السماح بمعلمات إضافية (الطريقة البطيئة ™)، يمكنك القيام بذلك باستخدام إجراء بسيط قبل الإجراء في 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
إذا كانت لديك بعض مربعات الاختيار التي تعبر عن الأدوار التي قد يتخذها المستخدم عند التسجيل، فسيرسل المتصفح مربعات الاختيار المحددة هذه كمصفوفة. المصفوفة ليست واحدة من الكميات المسموح بها للمعلمات القوية، لذلك نحتاج إلى تكوين 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 عبارة عن محرك، فإن جميع مشاهداته مجمعة داخل الجوهرة. ستساعدك طرق العرض هذه على البدء، ولكن قد ترغب في تغييرها بعد مرور بعض الوقت. إذا كان الأمر كذلك، فأنت بحاجة فقط إلى استدعاء المولد التالي، وسيقوم بنسخ جميع طرق العرض إلى تطبيقك:
rails generate devise:views
إذا كان لديك أكثر من نموذج Devise في تطبيقك (مثل User
و Admin
)، فستلاحظ أن Devise يستخدم نفس طرق العرض لجميع النماذج. ولحسن الحظ، يوفر Devise طريقة سهلة لتخصيص طرق العرض. كل ما عليك فعله هو تعيين config.scoped_views = true
داخل ملف config/initializers/devise.rb
.
بعد القيام بذلك، ستتمكن من الحصول على طرق عرض بناءً على الدور مثل 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
. ستستمر ريلز في استخدام طرق العرض من 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. وهو يقبل العديد من الخيارات مثل:class_name و:path_prefix وما إلى ذلك، بما في ذلك إمكانية تغيير أسماء المسارات لـ 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' }
تأكد من مراجعة وثائق devise_for
للحصول على التفاصيل.
إذا كنت بحاجة إلى مزيد من التخصيص العميق، على سبيل المثال للسماح أيضًا بـ "/sign_in" إلى جانب "/users/sign_in"، فكل ما عليك فعله هو إنشاء مساراتك بشكل طبيعي ولفها في كتلة devise_scope
في جهاز التوجيه:
devise_scope :user do
get 'sign_in' , to : 'devise/sessions#new'
end
بهذه الطريقة، يمكنك إخبار Devise باستخدام النطاق :user
عند الوصول إلى "/sign_in". لاحظ أيضًا أن اسم devise_scope
مستعار كما as
في جهاز التوجيه الخاص بك.
يرجى ملاحظة: ستظل بحاجة إلى إضافة devise_for
في مساراتك حتى تتمكن من استخدام الأساليب المساعدة مثل current_user
.
devise_for :users , skip : :all
يتكامل Devise مع 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
3.1.0
أو أعلى، يرجى التأكد من تحديثه إذا كنت ستستخدم هذا التكوين. تحقق من دليل الترقية هذا لمزيد من المعلومات.
ملاحظة : قد يصبح تكوين الحالات المذكورة أعلاه هو الإعداد الافتراضي لـ Devise في إصدار مستقبلي.
هناك بعض التغييرات الأخرى التي قد تحتاج إلى إجرائها في تطبيقك للعمل مع Hotwire/Turbo، إذا كنت تقوم بالترحيل من Rails-ujs:
data-confirm
الذي يضيف نموذج تأكيد إلى الأزرار/النماذج قبل الإرسال إلى التغيير إلى data-turbo-confirm
، بحيث يتعامل Turbo مع تلك العناصر بشكل مناسب.data-method
الذي يحدد طريقة الطلب لعمليات إرسال الارتباط إلى التغيير إلى data-turbo-method
. هذا ليس ضروريًا لـ button_to
أو form
s نظرًا لأن Turbo يمكنه التعامل معهما. إذا كنت تقوم بإعداد Devise لتسجيل الخروج عبر :delete
، وكنت تستخدم الروابط (بدلاً من الأزرار المغلفة في نموذج) لتسجيل الخروج باستخدام method: :delete
، فستحتاج إلى التحديث كما هو موضح أعلاه. (لا يوفر Devise روابط/أزرار تسجيل الخروج في طرق العرض المشتركة الخاصة به.)
تأكد من فحص وجهات نظرك بحثًا عن تلك وتغييرها بشكل مناسب.
يستخدم Devise رسائل الفلاش مع 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 Controllers من ApplicationController. إذا كان تطبيقك يستخدم لغات متعددة، فيجب عليك التأكد من تعيين I18n.locale في ApplicationController.
يتضمن Devise بعض مساعدي الاختبار لاختبارات التحكم والتكامل. من أجل استخدامها، تحتاج إلى تضمين الوحدة المعنية في حالات الاختبار/المواصفات الخاصة بك.
تتطلب اختبارات وحدة التحكم تضمين Devise::Test::IntegrationHelpers
في حالة الاختبار الخاصة بك أو الفئة الفائقة ActionController::TestCase
الأصلية الخاصة بها. بالنسبة لإصدارات Rails قبل الإصدار 5، قم بتضمين Devise::Test::ControllerHelpers
بدلاً من ذلك، حيث تم تغيير الفئة الفائقة لاختبارات وحدة التحكم إلى ActionDispatch::IntegrationTest (لمزيد من التفاصيل، راجع قسم اختبارات التكامل).
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
(أو spec/rails_helper.rb
إذا كنت تستخدم rspec-rails
):
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 : :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
على عكس اختبارات وحدة التحكم، لا تحتاج اختبارات التكامل إلى توفير قيمة env
devise.mapping
، حيث يمكن استنتاج التعيين من خلال المسارات التي يتم تنفيذها في اختباراتك.
يمكنك قراءة المزيد حول اختبار وحدات تحكم Rails باستخدام RSpec في الويكي:
يأتي Devise مع دعم OmniAuth خارج الصندوق للمصادقة مع مقدمي الخدمة الآخرين. لاستخدامه، ما عليك سوى تحديد إعدادات OmniAuth الخاصة بك في config/initializers/devise.rb
:
config . omniauth :github , 'APP_ID' , 'APP_SECRET' , scope : 'user,public_repo'
يمكنك قراءة المزيد حول دعم OmniAuth في الويكي:
يسمح لك Devise بإعداد العدد الذي تريده من نماذج Devise. إذا كنت تريد أن يكون لديك نموذج مسؤول يحتوي فقط على ميزات المصادقة والمهلة، بالإضافة إلى نموذج المستخدم أعلاه، فما عليك سوى تشغيل:
# 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 generator.
ضع في اعتبارك أن هذه النماذج سيكون لها طرق مختلفة تمامًا. إنهم لا يشاركون ولا يمكنهم مشاركة نفس وحدة التحكم لتسجيل الدخول وتسجيل الخروج وما إلى ذلك. في حالة رغبتك في الحصول على أدوار مختلفة تتشارك في نفس الإجراءات، نوصي باستخدام نهج قائم على الأدوار، إما عن طريق توفير عمود الدور أو استخدام جوهرة مخصصة للترخيص.
إذا كنت تستخدم Active Job لتسليم رسائل Action Mailer في الخلفية من خلال الواجهة الخلفية لقائمة الانتظار، فيمكنك إرسال رسائل بريد إلكتروني Devise من خلال قائمة الانتظار الحالية عن طريق تجاوز طريقة send_devise_notification
في النموذج الخاص بك.
def send_devise_notification ( notification , * args )
devise_mailer . send ( notification , self , * args ) . deliver_later
end
إذا قمت بتمكين الوحدة القابلة للاسترداد، لاحظ أن رمز إعادة تعيين كلمة المرور المسروقة يمكن أن يمنح المهاجم إمكانية الوصول إلى التطبيق الخاص بك. يبذل Devise جهدًا لإنشاء رموز مميزة عشوائية وآمنة، ويخزن ملخصات الرموز المميزة فقط في قاعدة البيانات، وليس نصًا عاديًا أبدًا. ومع ذلك، يمكن أن يتسبب سلوك التسجيل الافتراضي في Rails في تسرب الرموز المميزة للنص العادي إلى ملفات السجل:
deliver_later
لإرسال رسائل بريد إلكتروني لإعادة تعيين كلمة المرور، فسيتم تسريب الرموز المميزة لإعادة تعيين كلمة المرور. يقوم ريلز بتعيين مستوى مسجل الإنتاج إلى INFO افتراضيًا. فكر في تغيير مستوى مسجل الإنتاج الخاص بك إلى WARN إذا كنت ترغب في منع تسرب الرموز المميزة إلى سجلاتك. في config/environments/production.rb
:
config . log_level = :warn
يدعم Devise ActiveRecord (الافتراضي) وMongoid. لتحديد ORM آخر، ما عليك سوى طلبه في ملف التهيئة.
يحتوي الإصدار 5+ من Rails على وضع API مدمج يعمل على تحسين استخدام Rails كواجهة برمجة التطبيقات (فقط). Devise قادر إلى حد ما على التعامل مع التطبيقات المبنية في هذا الوضع دون تعديلات إضافية، بمعنى أنه لا ينبغي له رفع الاستثناءات وما شابه. ولكن قد تظهر بعض المشكلات أثناء development
/ testing
، لأننا ما زلنا لا نعرف المدى الكامل لهذا التوافق. (وللمزيد من المعلومات راجع العدد رقم: 4947)
لا تدعم تطبيقات API فقط المصادقة المستندة إلى المتصفح عبر ملفات تعريف الارتباط، وهو الإعداد الافتراضي للجهاز. ومع ذلك، لا يزال بإمكان devise توفير المصادقة المبتكرة في تلك الحالات باستخدام إستراتيجية http_authenticatable
، التي تستخدم مصادقة HTTP الأساسية وتصادق المستخدم في كل طلب. (لمزيد من المعلومات، راجع مقالة wiki هذه حول كيفية: استخدام مصادقة HTTP الأساسية)
تم تعطيل الإعداد الافتراضي لـ HTTP Auth، لذا يجب تمكينه في أداة تهيئة التصميم لاستراتيجية قاعدة البيانات:
config . http_authenticatable = [ :database ]
لا يمنعك هذا التقييد من تنفيذ إستراتيجيات الحراسة المخصصة، سواء في تطبيقك أو عبر الامتدادات المستندة إلى الأحجار الكريمة للتصميم. إحدى استراتيجيات المصادقة الشائعة لواجهات برمجة التطبيقات هي المصادقة المستندة إلى الرمز المميز. لمزيد من المعلومات حول توسيع التصميم لدعم هذا النوع من المصادقة وغيره، راجع مقالة wiki الخاصة بأمثلة وبدائل مصادقة الرمز البسيط أو منشور المدونة هذا حول طرق المصادقة المخصصة باستخدام Devise.
يغير وضع API ترتيب مكدس البرامج الوسيطة، وقد يتسبب هذا في حدوث مشكلات لـ Devise::Test::IntegrationHelpers
. تظهر هذه المشكلة عادةً كطريقة undefined method `[]=' for nil:NilClass
عند استخدام مساعدات اختبار التكامل، مثل #sign_in
. الحل ببساطة هو إعادة ترتيب البرامج الوسيطة عن طريق إضافة ما يلي إلى test.rb:
Rails . application