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