المستخدمون في مشاريع Firebase

يمثّل كائن user في Firebase حساب مستخدم تم توقيعه للحصول على تطبيق في مشروعك. عادة ما يكون للتطبيقات العديد من المستخدمين المسجلين، ويحصل كل تطبيق في أن المشروع يشارك قاعدة بيانات المستخدم.

وتكون مثيلات المستخدم مستقلة عن مثيلات مصادقة Firebase، لذا يمكنك الحصول على مراجع متعددة لمستخدمين مختلفين في نفس السياق وما زالوا يستدعي أي أساليبه.

خصائص المستخدمين

يمتلك مستخدمو Firebase مجموعة ثابتة من الخصائص الأساسية، وهي خصائص فريدة مستند تعريف الهوية وعنوان بريد إلكتروني رئيسي واسم وعنوان URL لصورة، يتم تخزينهما في لقاعدة بيانات مستخدم المشروع، والتي يمكن للمستخدم تحديثها (نظام التشغيل iOS و Android، الويب). لا يمكنك إضافة سمات أخرى إلى عنصر المستخدم مباشرةً، بدلاً من ذلك، يمكنك تخزين الخصائص الإضافية في أي خدمات تخزين أخرى، مثل Google Cloud متجر إطفاء

في المرة الأولى التي يشترك فيها المستخدم في تطبيقك، تتم تعبئة بيانات الملف الشخصي للمستخدم. باستخدام المعلومات المتاحة:

  • إذا اشترك المستخدم باستخدام عنوان بريد إلكتروني وكلمة مرور، فلن يتم تعبئة سمة عنوان البريد الإلكتروني
  • إذا اشترك المستخدم مع موفِّر هوية موحدة، مثل Google أو Facebook، تُستخدم معلومات الحساب التي يوفرها مزوّد الخدمة تعبئة الملف الشخصي للمستخدم
  • إذا اشترك المستخدم في نظام المصادقة المخصص، يجب إضافة المعلومات التي تريدها إلى الملف الشخصي للمستخدم

بعد إنشاء حساب مستخدم، يمكنك إعادة تحميل معلومات المستخدم إلى دمج أي تغييرات ربما أجراها المستخدم على جهاز آخر.

مقدّمو الخدمات الذين يسجِّلون الدخول

يمكنك تسجيل دخول المستخدمين إلى تطبيقاتك بعدة طرق: عنوان البريد الإلكتروني وكلمة المرور، وموفّرو الهوية الموحّدة، والمصادقة المخصّصة . يمكنك ربط أكثر من طريقة تسجيل دخول واحدة بأحد المستخدمين: على سبيل المثال، يمكن للمستخدم تسجيل الدخول إلى الحساب نفسه باستخدام عنوان بريد إلكتروني وكلمة مرور، أو باستخدام تسجيل الدخول باستخدام Google.

تتتبّع مثيلات المستخدم كل مقدّم خدمة مرتبط بالمستخدم. يتيح لك ذلك لتعديل سمات الملف التجاري الفارغة باستخدام المعلومات التي يوفّرها أحد الموفّرين. الاطلاع على "إدارة المستخدمين" (نظام التشغيل iOS و Android، الويب).

المستخدم الحالي

عندما يشترك مستخدم أو يسجّل دخوله، يصبح هذا المستخدم هو المستخدم الحالي مثيل المصادقة. يستمر المثيل في حالة المستخدم، لكي يتم تحديث (في المتصفح) أو إعادة تشغيل التطبيق لا يؤدي إلى فقدان المعلومات.

عندما يسجِّل المستخدم خروجه، يتوقف مثيل المصادقة عن الاحتفاظ بمرجع للمستخدم. كائن ولم تعد تحتفظ بحالتها؛ عدم وجود مستخدم حالي. ومع ذلك، عمل مثيل المستخدم بشكل كامل: إذا ارجعت إلى فلا يزال بإمكانك الوصول إلى بيانات المستخدم وتحديثها.

دورة حياة المستخدم

تتمثل الطريقة الموصى بها لتتبّع الحالة الحالية لمثيل Auth في استخدام المستمعين (يطلق عليهم أيضًا "المراقبون" في JavaScript). يحصل مستمع المصادقة على الإشعارات في أي وقت يحدث فيه شيء ذا صلة لعنصر "المصادقة". الاطّلاع على قسم "الإدارة" المستخدمون (نظام التشغيل iOS و Android، الويب).

يتلقّى مستمع المصادقة إشعارات في الحالات التالية:

  • يكتمل إعداد عنصر المصادقة، وسبق أن سجَّل المستخدم الدخول من جلسة سابقة، أو تمت إعادة توجيهها من عملية تسجيل دخول موفر الهوية تدفّق
  • يسجِّل مستخدم الدخول (تم تحديد المستخدم الحالي)
  • يسجِّل المستخدم خروجه (يصبح المستخدم الحالي فارغًا)
  • تتم إعادة تحميل رمز الدخول للمستخدم الحالي. يمكن أن تحدث هذه الحالة في الشروط التالية:
    • تنتهي صلاحية رمز الدخول: هذه حالة شائعة. الرمز المميز للتحديث هو تُستخدم للحصول على مجموعة صالحة جديدة من الرموز المميزة.
    • تغيير المستخدم لكلمة المرور: يُصدر Firebase إذن وصول جديد وتحديث الرموز المميزة وعرض انتهاء صلاحية الرموز المميزة سيتم إجراء ذلك تلقائيًا انتهاء صلاحية الرمز المميز للمستخدم و/أو تسجيل خروج المستخدم على كل جهاز، لأسباب تتعلق بالأمان.
    • يعيد المستخدم المصادقة: تتطلب بعض الإجراءات أن يكون المستخدم بيانات الاعتماد الصادرة مؤخرًا مثل حذف حساب، إعداد عنوان بريد إلكتروني أساسي، وتغيير كلمة مرور. بدلاً من تسجيل خروج المستخدم ثم تسجيل دخول المستخدم مرة أخرى، والحصول على بيانات الاعتماد من المستخدم، وتمرير بيانات الاعتماد الجديدة إلى لإعادة مصادقة كائن المستخدم.

الخدمة الذاتية للمستخدم

يتيح Firebase تلقائيًا للمستخدمين الاشتراك وحذف حساباتهم بدون تدخل إداري. في العديد من الظروف، يمكّن ذلك للمستخدمين النهائيين باكتشاف تطبيقك أو خدمتك وإعدادهما (أو خارجه) مع الحد الأدنى من الاحتكاك.

ومع ذلك، هناك مواقف تريد فيها أن يتم توجيه المستخدمين يدويًا أو تم إنشاؤها آليًا من قبل مشرف، إما باستخدام SDK للمشرف أو "وحدة تحكُّم Firebase". في هذه الحالات، يمكنك إيقاف إجراءات المستخدم من إعدادات مصادقة Firebase ، ما يمنع إنشاء الحسابات وحذفها من قِبل المستخدمين النهائيين. إذا كنت تستخدم نظام إقامة متعدد، فستحتاج إلى تقديم طلب 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 في عنوان البريد الإلكتروني الذي تم التحقق منه في حال استيفائه الشرطين التاليين:

  1. يُكمل المستخدم عملية إثبات الملكية في Firebase.
  2. يتم إثبات ملكية عنوان البريد الإلكتروني من خلال موفِّر هوية موثوق به أو موفِّر هوية (IdP) لفترة قصيرة.

لا يُعد موفِّرو الهوية (IdP) الذين يثبتون ملكية البريد الإلكتروني مرة واحدة، ثم يسمحون للمستخدمين بعد ذلك بتغيير عناوين البريد الإلكتروني بدون الحاجة إلى إعادة إثبات الملكية، موثوقًا بهم. إنّ موفِّري الهوية الذين يملكون النطاق أو الذين يطلبون دائمًا إثبات الملكية يعتبرون موثوقًا بهم.

مقدّمو الخدمات الموثوق بهم:

  • Google (لعناوين @gmail.com)
  • Yahoo (لعناوين @yahoo.com)
  • Microsoft (لعناوين @outlook.com و @hotmail.com)
  • Apple (يتم التحقق منه دائمًا، لأنّ الحسابات يتم التحقق منها دائمًا وتتم مصادقتها باستخدام عدة عوامل)

مزوِّدو الخدمة غير الموثوق بهم:

  • Facebook
  • Twitter
  • GitHub
  • Google وYahoo وMicrosoft للنطاقات التي لم يصدرها موفّر الهوية هذا
  • عنوان البريد الإلكتروني / كلمة المرور بدون إثبات ملكية عنوان البريد الإلكتروني

في بعض الحالات، سيعمل Firebase تلقائيًا على ربط الحسابات عندما يسجِّل المستخدم دخوله من خلال مقدّمي خدمات مختلفين باستخدام عنوان البريد الإلكتروني نفسه. ومع ذلك، لا يمكن أن يحدث هذا إلا عند استيفاء معايير محددة. لفهم السبب، ضع في اعتبارك الموقف التالي: يسجّل أحد المستخدمين الدخول باستخدام Google باستخدام حساب @gmail.com وأنشأ أحد الجهات المسيئة حسابًا باستخدام عنوان @gmail.com نفسه، ولكن مع تسجيل الدخول عبر Facebook. فإذا تم ربط هذين الحسابين تلقائيًا، فسيتسنى للجهة المسيئة الوصول إلى حساب المستخدم.

تصف الحالات التالية الحالات التي نربط فيها الحسابات تلقائيًا وعند عرض رسالة خطأ تتطلب من المستخدم أو المطوّر اتخاذ إجراء:

  • يسجِّل المستخدم الدخول من خلال مقدِّم خدمة غير موثوق به، ثم يسجِّل الدخول من خلال موفِّر خدمة آخر غير موثوق به باستخدام البريد الإلكتروني نفسه (على سبيل المثال، Facebook متبوعًا بـ GitHub). يؤدي ذلك إلى حدوث خطأ يتطلب ربط الحساب.
  • يسجِّل المستخدم الدخول من خلال مقدِّم خدمة موثوق به، ثم يسجِّل الدخول من خلال مقدِّم خدمة غير موثوق به باستخدام البريد الإلكتروني نفسه (على سبيل المثال، حساب Google متبوعًا بـ Facebook). يؤدي ذلك إلى حدوث خطأ يتطلب ربط الحساب.
  • يسجِّل المستخدم الدخول من خلال مقدِّم خدمة غير موثوق به، ثم يسجِّل الدخول من خلال مقدِّم خدمة موثوق به باستخدام البريد الإلكتروني نفسه (على سبيل المثال، Facebook متبوعًا بـ Google). ويستبدل مقدم الخدمة الموثوق به مقدم الخدمة غير الموثوق به. إذا حاول المستخدم تسجيل الدخول مرة أخرى باستخدام Facebook، سيؤدي ذلك إلى حدوث خطأ يتطلّب ربط الحساب.
  • يسجِّل المستخدم الدخول من خلال مقدّم خدمة موثوق به، ثم يسجّل الدخول من خلال مقدّم خدمة موثوق آخر باستخدام عنوان البريد الإلكتروني نفسه (على سبيل المثال، Apple تليها Google). سيتم ربط كلا المزودين بدون أخطاء.

يمكنك يدويًا ضبط عنوان بريد إلكتروني تم إثبات ملكيته باستخدام حزمة تطوير البرامج (SDK) الخاصة بالمشرف، ولكن ننصحك بعدم إجراء ذلك إلا إذا كنت تعرف أنّ المستخدِم يملك هذا البريد الإلكتروني.