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