يمثّل الكائن Firebase Authentication المستخدم حساب مستخدم اشترك في تطبيق في مشروعك. عادةً ما يكون للتطبيقات العديد من المستخدمين المسجّلين، وتتشارك جميع التطبيقات في مشروع قاعدة بيانات للمستخدمين.
تكون مثيلات المستخدمين مستقلة عن Firebase Authentication مثيلات، لذا يمكنك الحصول على عدة مراجع لمستخدمين مختلفين ضمن السياق نفسه واستدعاء أي من طرقهم.
خصائص المستخدمين
لدى مستخدمي Authentication مجموعة ثابتة من الخصائص الأساسية، وهي معرّف فريد وعنوان البريد الإلكتروني الرئيسي واسم وعنوان URL لصورة، يتم تخزينها في قاعدة بيانات المستخدمين في المشروع، ويمكن للمستخدم تعديلها (على أجهزة iOS وAndroid والويب). لا يمكنك إضافة خصائص أخرى إلى كائن المستخدم مباشرةً، ولكن يمكنك بدلاً من ذلك تخزين الخصائص الإضافية في أي خدمات تخزين أخرى، مثل Google Cloud Firestore.
في المرة الأولى التي يشترك فيها مستخدم في تطبيقك، تتم تعبئة بيانات الملف الشخصي للمستخدم باستخدام المعلومات المتاحة:
- إذا اشترك المستخدم باستخدام عنوان بريد إلكتروني وكلمة مرور، يتم ملء خاصية عنوان البريد الإلكتروني الأساسي فقط.
- إذا اشترك المستخدم باستخدام موفّر هوية موحّدة، مثل Google أو Facebook، يتم استخدام معلومات الحساب التي يوفّرها الموفّر لملء الملف الشخصي للمستخدم.
- إذا اشترك المستخدم باستخدام نظام المصادقة المخصّص، عليك إضافة المعلومات التي تريدها إلى الملف الشخصي للمستخدم بشكلٍ صريح.
بعد إنشاء حساب مستخدم، يمكنك إعادة تحميل معلومات المستخدم لدمج أي تغييرات قد يكون المستخدم قد أجراها على جهاز آخر.
موفّرو تسجيل الدخول
يمكنك تسجيل دخول المستخدمين إلى تطبيقاتك باستخدام عدة طرق: عنوان البريد الإلكتروني وكلمة المرور، وموفّرو الهوية الموحّدة، ونظام المصادقة المخصّص. يمكنك ربط أكثر من طريقة لتسجيل الدخول بمستخدم واحد: على سبيل المثال، يمكن للمستخدم تسجيل الدخول إلى الحساب نفسه باستخدام عنوان بريد إلكتروني وكلمة مرور، أو باستخدام ميزة "تسجيل الدخول باستخدام حساب Google".
تحتفظ مثيلات المستخدمين بسجلّ لكل موفّر مرتبط بالمستخدم. يتيح لك ذلك تعديل خصائص الملف الشخصي الفارغ باستخدام المعلومات التي يقدّمها الموفّر. راجِع مقالة إدارة المستخدمين (على أجهزة iOS، Android، والويب).
المستخدم الحالي
عندما يشترك مستخدم أو يسجّل الدخول، يصبح هذا المستخدم هو المستخدم الحالي لمثيل Auth. يحتفظ المثيل بحالة المستخدم، لذا لا يؤدي إعادة تحميل الصفحة (في متصفح) أو إعادة تشغيل التطبيق إلى فقدان معلومات المستخدم.
عندما يسجّل المستخدم الخروج، يتوقف مثيل Auth عن الاحتفاظ بمرجع لكائن المستخدم ولا يعود يحتفظ بحالته، ولا يكون هناك مستخدم حالي. ومع ذلك، يظلّ مثيل المستخدم يعمل بشكلٍ كامل: إذا احتفظت بمرجع له، سيظلّ بإمكانك الوصول إلى بيانات المستخدم وتعديلها.
مراحل نشاط المستخدم
الطريقة المقترَحة لتتبُّع الحالة الحالية لمثيل Auth هي استخدام المستمعين (المعروفين أيضًا باسم "المراقبين" في JavaScript). يتم إعلام مستمع Auth في أي وقت يحدث فيه شيء ذو صلة بكائن Auth. راجِع مقالة إدارة المستخدمين (على أجهزة iOS، وAndroid، والويب).
يتم إعلام مستمع Auth في الحالات التالية:
- ينتهي مثيل Auth من التهيئة وقد يكون المستخدم قد سجّل الدخول من جلسة سابقة، أو تمت إعادة توجيهه من عملية تسجيل الدخول لموفّر الهوية.
- يسجّل المستخدم الدخول (يتم ضبط المستخدم الحالي).
- يسجّل المستخدم الخروج (يصبح المستخدم الحالي فارغًا).
- يتم إعادة تحميل رمز الدخول المميز للمستخدم الحالي. يمكن أن تحدث هذه الحالة في الظروف التالية:
- تنتهي صلاحية رمز الدخول المميز: هذا موقف شائع. يُستخدَم الرمز المميز لإعادة التحميل للحصول على مجموعة جديدة من الرموز المميزة الصالحة.
- يغيّر المستخدم كلمة المرور: Authentication تصدر رموز دخول مميزة ورموز إعادة تحميل جديدة وتجعل الرموز القديمة منتهية الصلاحية. يؤدي ذلك تلقائيًا إلى انتهاء صلاحية الرمز المميز للمستخدم و/أو تسجيل خروجه على كل جهاز، لأسباب أمنية.
- يعيد المستخدم المصادقة: تتطلب بعض الإجراءات أن تكون بيانات اعتماد المستخدم صادرة حديثًا، وتشمل هذه الإجراءات حذف حساب وتعيين عنوان بريد إلكتروني أساسي وتغيير كلمة مرور. بدلاً من تسجيل خروج المستخدم ثم تسجيل دخوله مرة أخرى، احصل على بيانات اعتماد جديدة من المستخدم، ومرِّر بيانات الاعتماد الجديدة إلى طريقة reauthenticate الخاصة بكائن المستخدم.
الخدمة الذاتية للمستخدم
تتيح خدمة Firebase Authentication للمستخدمين بشكلٍ تلقائي الاشتراك وحذف حساباتهم بدون تدخّل إداري. في ظروف عديدة، يتيح ذلك للمستخدمين النهائيين اكتشاف تطبيقك أو خدمتك وإعدادها (أو إيقاف استخدامها) بأقل قدر من المشاكل.
ومع ذلك، هناك حالات تريد فيها أن ينشئ المشرف المستخدمين يدويًا أو آليًا، إما باستخدام Admin SDK أو Firebase console. في هذه الحالات، يمكنك إيقاف إجراءات المستخدم من صفحة Firebase Authenticationالإعدادات ، ما يمنع المستخدمين النهائيين من إنشاء الحسابات وحذفها. إذا كنت تستخدم ميزة "تعدّد المستأجرين"، عليك إرسال طلب HTTP لإيقاف هذه الميزات على أساس كل مستأجر.
إذا حاول مستخدم نهائي إنشاء حساب أو حذفه ضمن نظامك، ستعرض خدمة
Firebase Authentication رمز خطأ:
auth/admin-restricted-operation لطلبات Web API، أو ERROR_ADMIN_RESTRICTED_OPERATION لأجهزة Android وiOS. عليك معالجة الخطأ بشكلٍ سليم على واجهة العرض الأمامية من خلال مطالبة المستخدم باتخاذ الإجراءات المناسبة لخدمتك.
رموز المصادقة
عند إجراء المصادقة باستخدام Authentication، هناك ثلاثة أنواع من رموز المصادقة التي قد تواجهها:
| رموز تعريف Authentication | تنشئها Authentication عندما يسجّل المستخدم الدخول إلى تطبيق. هذه الرموز المميزة هي رموز JWT موقَّعة تحدّد بشكلٍ آمن هوية مستخدم في Firebase مشروع. تحتوي هذه الرموز المميزة على معلومات أساسية عن الملف الشخصي ل لمستخدم، بما في ذلك سلسلة رقم تعريف المستخدم، وهي فريدة ل Firebaseلمشروع. بما أنّه يمكن التحقّق من سلامة رموز تعريف الهوية ، يمكنك إرسالها إلى خادم الخلفية لتحديد المستخدم الذي سجّل الدخول حاليًا. |
| رموز موفّر الهوية | تنشئها موفّرو الهوية الموحّدة، مثل Google وFacebook. يمكن أن تتخذ هذه الرموز المميزة تنسيقات مختلفة، ولكنها غالبًا ما تكون رموز دخول مميزة لبروتوكول OAuth 2.0 رموز مميزة. تستخدم التطبيقات هذه الرموز المميزة للتحقّق من أنّ المستخدمين قد نجحوا في المصادقة باستخدام موفّر الهوية، ثم تحويلها إلى بيانات اعتماد يمكن أن تستخدمها خدمات Authentication. |
| الرموز المميزة المخصّصة Authentication | تنشئها أنظمة المصادقة المخصّصة للسماح للمستخدمين بتسجيل الدخول إلى تطبيق باستخدام نظام المصادقة. الرموز المميزة المخصّصة هي رموز JWT موقَّعة باستخدام المفتاح الخاص لحساب الخدمة. تستخدم التطبيقات هذه الرموز المميزة تمامًا كما تستخدم الرموز المميزة التي يتم عرضها من موفّري الهوية الموحّدة. |
عناوين البريد الإلكتروني التي تم التحقّق منها
Authentication تعتبر خدمة المصادقة عنوان البريد الإلكتروني تم التحقّق منه إذا استوفى شرطَين:
- يكمل المستخدم عملية التحقّق من Authentication.
- يتم التحقّق من عنوان البريد الإلكتروني من قِبل موفّر هوية موثوق به، أو IdP باختصار.
لا يُعتبر موفّرو الهوية موثوقين إذا تحقّقوا من عنوان البريد الإلكتروني مرة واحدة، ثم سمحوا للمستخدمين بتغيير عناوين البريد الإلكتروني بدون طلب إعادة التحقّق. يُعتبر موفّرو الهوية موثوقين إذا كانوا يملكون النطاق أو كانوا يطلبون التحقّق دائمًا.
موفّرو الخدمات الموثوق بهم:
- Google (لعناوين @gmail.com)
- Yahoo (لعناوين @yahoo.com)
- Microsoft (لعناوين @outlook.com و @hotmail.com)
- Apple (يتم التحقّق دائمًا من عناوين البريد الإلكتروني، لأنّه يتم دائمًا التحقّق من الحسابات وإجراء مصادقة متعدّدة العوامل)
موفّرو الخدمات غير الموثوق بهم:
- GitHub
- Google وYahoo وMicrosoft للنطاقات التي لم يصدرها موفّر الهوية هذا
- البريد الإلكتروني / كلمة المرور بدون تأكيد عنوان البريد الإلكتروني
في بعض الحالات، ستربط Authentication الحسابات تلقائيًا عندما يسجّل المستخدم الدخول باستخدام موفّرين مختلفَين باستخدام عنوان البريد الإلكتروني نفسه. لا يمكن أن يحدث ذلك إلا عند استيفاء معايير معيّنة. لفهم السبب، ضع في اعتبارك الحالة التالية: يسجّل المستخدم الدخول باستخدام Google باستخدام حساب @gmail.com وينشئ مستخدم ضار حسابًا باستخدام عنوان @gmail.com نفسه، ولكن يسجّل الدخول عبر Facebook. إذا تم ربط هذين الحسابَين تلقائيًا، ستتمكّن الجهة المسيئة من الوصول إلى حساب المستخدم.
تصف الحالات التالية متى نربط الحسابات تلقائيًا ومتى نعرض خطأ يتطلب إجراءً من المستخدم أو المطوّر:
- يسجّل المستخدم الدخول باستخدام موفّر غير موثوق به، ثم يسجّل الدخول باستخدام موفّر آخر غير موثوق به باستخدام عنوان البريد الإلكتروني نفسه (على سبيل المثال، Facebook متبوعًا بـ GitHub). يعرض ذلك خطأ يتطلب ربط الحساب.
- يسجّل المستخدم الدخول باستخدام موفّر موثوق به، ثم يسجّل الدخول باستخدام موفّر غير موثوق به باستخدام عنوان البريد الإلكتروني نفسه (على سبيل المثال، Google متبوعًا بـ Facebook). يعرض ذلك خطأ يتطلب ربط الحساب.
- يسجّل المستخدم الدخول باستخدام موفّر غير موثوق به، ثم يسجّل الدخول باستخدام موفّر موثوق به باستخدام عنوان البريد الإلكتروني نفسه (على سبيل المثال، Facebook متبوعًا بـ Google). يستبدل الموفّر الموثوق به الموفّر غير الموثوق به. إذا حاول المستخدم تسجيل الدخول مرة أخرى باستخدام Facebook، سيؤدي ذلك إلى حدوث خطأ يتطلب ربط الحساب.
- يسجّل المستخدم الدخول باستخدام موفّر موثوق به، ثم يسجّل الدخول باستخدام موفّر موثوق به مختلف باستخدام عنوان البريد الإلكتروني نفسه (على سبيل المثال، Apple متبوعًا بـ Google). سيتم ربط كلا الموفّرَين بدون أخطاء.
يمكنك ضبط عنوان بريد إلكتروني يدويًا على أنّه تم التحقّق منه باستخدام Admin SDK، ولكن ننصحك بإجراء ذلك فقط إذا كنت تعرف أنّ المستخدم يملك عنوان البريد الإلكتروني فعلاً.