المستخدمون في مشاريع Firebase (original) (raw)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يتيح 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 في حال استيفاء الشرطين التاليين:

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

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

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

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

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

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

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