يمثل كائن مستخدم Firebase حساب مستخدم قام بالتسجيل في تطبيق في مشروعك. تحتوي التطبيقات عادةً على العديد من المستخدمين المسجلين، ويشارك كل تطبيق في المشروع قاعدة بيانات المستخدم.
تعتبر مثيلات المستخدم مستقلة عن مثيلات Firebase Authentication، لذا يمكنك الحصول على عدة مراجع لمستخدمين مختلفين ضمن نفس السياق مع الاستمرار في استدعاء أي من أساليبهم.
خصائص المستخدم
يمتلك مستخدمو Firebase مجموعة ثابتة من الخصائص الأساسية - معرف فريد، وعنوان بريد إلكتروني أساسي، واسم وعنوان URL للصورة - مخزنة في قاعدة بيانات مستخدم المشروع، والتي يمكن للمستخدم تحديثها ( iOS ، Android ، الويب ). لا يمكنك إضافة خصائص أخرى إلى كائن المستخدم مباشرة؛ بدلاً من ذلك، يمكنك تخزين الخصائص الإضافية في أي خدمات تخزين أخرى، مثل Google Cloud Firestore.
في المرة الأولى التي يقوم فيها المستخدم بالتسجيل في تطبيقك، تتم تعبئة بيانات الملف الشخصي للمستخدم باستخدام المعلومات المتاحة:
- إذا قام المستخدم بالتسجيل باستخدام عنوان بريد إلكتروني وكلمة مرور، فسيتم ملء خاصية عنوان البريد الإلكتروني الأساسي فقط
- إذا قام المستخدم بالتسجيل مع موفر هوية موحد، مثل Google أو Facebook، فسيتم استخدام معلومات الحساب التي يوفرها الموفر لملء الملف الشخصي للمستخدم
- إذا قام المستخدم بالتسجيل باستخدام نظام المصادقة المخصص الخاص بك، فيجب عليك إضافة المعلومات التي تريدها بشكل صريح إلى ملف تعريف المستخدم
بمجرد إنشاء حساب مستخدم، يمكنك إعادة تحميل معلومات المستخدم لدمج أي تغييرات قد يكون المستخدم قد أجراها على جهاز آخر.
موفري تسجيل الدخول
يمكنك تسجيل دخول المستخدمين إلى تطبيقاتك باستخدام عدة طرق: عنوان البريد الإلكتروني وكلمة المرور وموفري الهوية المتحدين ونظام المصادقة المخصص الخاص بك. يمكنك ربط أكثر من طريقة تسجيل دخول بمستخدم: على سبيل المثال، يمكن للمستخدم تسجيل الدخول إلى نفس الحساب باستخدام عنوان بريد إلكتروني وكلمة مرور، أو باستخدام تسجيل الدخول بحساب Google.
تقوم مثيلات المستخدم بتتبع كل مزود مرتبط بالمستخدم. يتيح لك ذلك تحديث خصائص ملف التعريف الفارغ باستخدام المعلومات المقدمة من قبل الموفر. راجع إدارة المستخدمين ( iOS ، Android ، الويب ).
المستخدم الحالي
عندما يقوم مستخدم بالتسجيل أو تسجيل الدخول، يصبح هذا المستخدم هو المستخدم الحالي لمثيل المصادقة. يحافظ المثيل على حالة المستخدم، بحيث لا يؤدي تحديث الصفحة (في المتصفح) أو إعادة تشغيل التطبيق إلى فقدان معلومات المستخدم.
عندما يقوم المستخدم بتسجيل الخروج، يتوقف مثيل المصادقة عن الاحتفاظ بمرجع إلى كائن المستخدم ولم يعد يحتفظ بحالته؛ لا يوجد مستخدم حالي. ومع ذلك، يستمر مثيل المستخدم في العمل بشكل كامل: إذا احتفظت بمرجع إليه، فلا يزال بإمكانك الوصول إلى بيانات المستخدم وتحديثها.
دورة حياة المستخدم
الطريقة الموصى بها لتتبع الحالة الحالية لمثيل Auth هي استخدام المستمعين (يُطلق عليهم أيضًا "المراقبون" في JavaScript). يتم إخطار مستمع المصادقة في أي وقت يحدث فيه شيء ذي صلة بكائن المصادقة. راجع إدارة المستخدمين ( iOS ، Android ، الويب ).
يتم إخطار مستمع المصادقة في المواقف التالية:
- انتهى كائن المصادقة من التهيئة وتم تسجيل دخول المستخدم بالفعل من جلسة سابقة، أو تمت إعادة توجيهه من تدفق تسجيل الدخول لموفر الهوية
- يقوم المستخدم بتسجيل الدخول (تم تعيين المستخدم الحالي)
- يقوم المستخدم بتسجيل الخروج (يصبح المستخدم الحالي خاليًا)
- يتم تحديث رمز الوصول للمستخدم الحالي. يمكن أن تحدث هذه الحالة في الحالات التالية:
- تنتهي صلاحية رمز الوصول: هذا موقف شائع. يتم استخدام رمز التحديث للحصول على مجموعة جديدة صالحة من الرموز المميزة.
- يقوم المستخدم بتغيير كلمة المرور الخاصة به: يُصدر Firebase رموزًا مميزة جديدة للوصول والتحديث ويجعل الرموز المميزة القديمة منتهية الصلاحية. يؤدي هذا تلقائيًا إلى انتهاء صلاحية الرمز المميز للمستخدم و/أو تسجيل خروج المستخدم على كل جهاز، لأسباب أمنية.
- إعادة مصادقة المستخدم: تتطلب بعض الإجراءات أن يتم إصدار بيانات اعتماد المستخدم مؤخرًا؛ تتضمن هذه الإجراءات حذف حساب، وتعيين عنوان بريد إلكتروني أساسي، وتغيير كلمة المرور. بدلاً من تسجيل خروج المستخدم ثم تسجيل الدخول مرة أخرى، احصل على بيانات اعتماد جديدة من المستخدم، وقم بتمرير بيانات الاعتماد الجديدة إلى أسلوب إعادة المصادقة لكائن المستخدم.
الخدمة الذاتية للمستخدم
افتراضيًا، يمكّن Firebase المستخدمين من التسجيل وحذف حساباتهم دون تدخل إداري. في العديد من الظروف، يتيح ذلك للمستخدمين النهائيين اكتشاف التطبيق أو الخدمة الخاصة بك وعلى متنها (أو خارجها) بأقل قدر من الاحتكاك.
ومع ذلك، هناك حالات تريد فيها إنشاء المستخدمين يدويًا أو برمجيًا بواسطة المشرف، إما باستخدام Admin SDK أو وحدة تحكم Firebase. في هذه الحالات، يمكنك تعطيل إجراءات المستخدم من صفحة إعدادات مصادقة Firebase ، مما يمنع المستخدمين النهائيين من إنشاء الحساب وحذفه. إذا كنت تستخدم الإيجارات المتعددة، فستحتاج إلى تقديم طلب HTTP لتعطيل هذه الميزات على أساس كل مستأجر.
إذا حاول مستخدم نهائي إنشاء حساب أو حذفه داخل نظامك، فستعرض خدمة Firebase رمز خطأ: auth/admin-restricted-operation لاستدعاءات Web API، أو ERROR_ADMIN_RESTRICTED_OPERATION لنظامي التشغيل Android وiOS. يجب عليك التعامل مع الخطأ في واجهتك الأمامية بأمان من خلال مطالبة المستخدم باتخاذ الإجراءات المناسبة لخدمتك.
رموز المصادقة
عند إجراء المصادقة باستخدام Firebase، هناك ثلاثة أنواع من رموز المصادقة المميزة التي قد تواجهها:
| الرموز المميزة لمعرف Firebase | يتم إنشاؤها بواسطة Firebase عندما يقوم المستخدم بتسجيل الدخول إلى أحد التطبيقات. هذه الرموز المميزة عبارة عن JWTs موقعة تحدد هوية المستخدم بشكل آمن في مشروع Firebase. تحتوي هذه الرموز المميزة على معلومات الملف الشخصي الأساسية للمستخدم، بما في ذلك سلسلة معرف المستخدم، وهي فريدة لمشروع Firebase. نظرًا لإمكانية التحقق من سلامة رموز المعرف ، يمكنك إرسالها إلى خادم الواجهة الخلفية لتحديد المستخدم الذي قام بتسجيل الدخول حاليًا. |
| الرموز المميزة لموفر الهوية | تم إنشاؤها بواسطة موفري الهوية المتحدين، مثل Google وFacebook. يمكن أن يكون لهذه الرموز المميزة تنسيقات مختلفة، ولكنها غالبًا ما تكون رموز وصول OAuth 2.0. تستخدم التطبيقات هذه الرموز المميزة للتحقق من نجاح المستخدمين في المصادقة مع موفر الهوية، ثم تحويلها إلى بيانات اعتماد قابلة للاستخدام بواسطة خدمات Firebase. |
| الرموز المخصصة لـ Firebase | تم إنشاؤه بواسطة نظام المصادقة المخصص الخاص بك للسماح للمستخدمين بتسجيل الدخول إلى التطبيق باستخدام نظام المصادقة الخاص بك. الرموز المخصصة هي JWTs موقعة باستخدام المفتاح الخاص لحساب الخدمة . تستخدم التطبيقات هذه الرموز المميزة مثلما تستخدم الرموز المميزة التي يتم إرجاعها من موفري الهوية المتحدين. |
عناوين البريد الإلكتروني التي تم التحقق منها
يعتبر Firebase أن البريد الإلكتروني قد تم التحقق منه إذا كان يستوفي شرطين:
- يُكمل المستخدم عملية التحقق من Firebase
- يتم التحقق من البريد الإلكتروني بواسطة موفر هوية موثوق به، أو IdP للاختصار.
إن موفري الهوية (IdPs) الذين يتحققون من البريد الإلكتروني مرة واحدة، ولكن بعد ذلك يسمحون للمستخدمين بتغيير عناوين البريد الإلكتروني دون الحاجة إلى إعادة التحقق، غير موثوق بهم. يعتبر مزوّدو الهوية (IdPs) الذين يمتلكون النطاق أو الذين يطلبون التحقق دائمًا، موثوقين.
مقدمو الخدمة الموثوق بهم:
- 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). يقوم الموفر الموثوق بالكتابة فوق الموفر غير الموثوق به. إذا حاول المستخدم تسجيل الدخول مرة أخرى باستخدام فيسبوك، فسيتسبب ذلك في حدوث خطأ يتطلب ربط الحساب.
- يقوم المستخدم بتسجيل الدخول مع موفر موثوق به، ثم يسجل الدخول مع موفر موثوق آخر بنفس البريد الإلكتروني (على سبيل المثال، Apple تليها Google). سيتم ربط كلا المزودين بدون أخطاء.
يمكنك تعيين بريد إلكتروني يدويًا على أنه تم التحقق منه باستخدام Admin SDK، لكننا نوصي بالقيام بذلك فقط إذا كنت تعلم أن المستخدم يمتلك البريد الإلكتروني بالفعل.