شی کاربر Firebase نشان دهنده یک حساب کاربری است که برای یک برنامه در پروژه شما ثبت نام کرده است. برنامه‌ها معمولاً کاربران ثبت‌شده زیادی دارند و هر برنامه در یک پروژه یک پایگاه داده کاربر را به اشتراک می‌گذارد.
نمونه های کاربر مستقل از نمونه های Firebase Authentication هستند، بنابراین می توانید چندین مرجع به کاربران مختلف در یک زمینه داشته باشید و همچنان هر یک از روش های آنها را فراخوانی کنید.
ویژگی های کاربر
کاربران Firebase دارای مجموعه ای ثابت از ویژگی های اولیه هستند - یک شناسه منحصر به فرد، یک آدرس ایمیل اصلی، یک نام و یک URL عکس - ذخیره شده در پایگاه داده کاربران پروژه، که می تواند توسط کاربر ( iOS ، Android ، وب ) به روز شود. شما نمی توانید ویژگی های دیگر را مستقیماً به شی کاربر اضافه کنید. در عوض، می‌توانید ویژگی‌های اضافی را در هر سرویس ذخیره‌سازی دیگری مانند Google Cloud Firestore ذخیره کنید.
اولین باری که کاربر در برنامه شما ثبت نام می کند، اطلاعات نمایه کاربر با استفاده از اطلاعات موجود تکمیل می شود:
- اگر کاربر با یک آدرس ایمیل و رمز عبور ثبت نام کرده باشد، فقط ویژگی آدرس ایمیل اصلی پر می شود
- اگر کاربر با یک ارائه دهنده هویت فدرال مانند گوگل یا فیس بوک ثبت نام کرده باشد، اطلاعات حسابی که توسط ارائه دهنده در دسترس است برای پر کردن نمایه کاربر استفاده می شود.
- اگر کاربر با سیستم احراز هویت سفارشی شما ثبت نام کرده است، باید صریحاً اطلاعات مورد نظر خود را به نمایه کاربر اضافه کنید.
هنگامی که یک حساب کاربری ایجاد شد، می توانید اطلاعات کاربر را مجدداً بارگیری کنید تا تغییراتی که کاربر ممکن است در دستگاه دیگری ایجاد کرده باشد، اضافه کنید.
ارائه دهندگان ورود به سیستم
می‌توانید با استفاده از چندین روش، کاربران را به برنامه‌های خود وارد کنید: آدرس ایمیل و رمز عبور، ارائه‌دهندگان هویت فدرال، و سیستم احراز هویت سفارشی‌تان. می‌توانید بیش از یک روش ورود به سیستم را با یک کاربر مرتبط کنید: برای مثال، یک کاربر می‌تواند با استفاده از آدرس ایمیل و رمز عبور یا با استفاده از Google Sign-In به همان حساب وارد شود.
نمونه‌های کاربر، هر ارائه‌دهنده‌ای را که به کاربر مرتبط است، ردیابی می‌کنند. این به شما امکان می دهد با استفاده از اطلاعات ارائه شده توسط یک ارائه دهنده، ویژگی های خالی نمایه را به روز کنید. به مدیریت کاربران ( iOS ، Android ، وب ) مراجعه کنید.
کاربر فعلی
هنگامی که یک کاربر ثبت نام می کند یا وارد سیستم می شود، آن کاربر کاربر فعلی نمونه Auth می شود. این نمونه وضعیت کاربر را حفظ می کند، به طوری که بازخوانی صفحه (در مرورگر) یا راه اندازی مجدد برنامه، اطلاعات کاربر را از دست نمی دهد.
هنگامی که کاربر از سیستم خارج می شود، نمونه Auth ارجاع به شی کاربر را متوقف می کند و دیگر حالت خود را حفظ نمی کند. کاربر فعلی وجود ندارد با این حال، نمونه کاربر همچنان کاملاً کاربردی است: اگر به آن اشاره ای داشته باشید، همچنان می توانید به داده های کاربر دسترسی داشته باشید و آن را به روز کنید.
چرخه عمر کاربر
روش توصیه شده برای ردیابی وضعیت فعلی نمونه Auth با استفاده از شنوندگان (که در جاوا اسکریپت "مشاهده" نیز نامیده می شود) است. یک شنونده Auth هر زمان که اتفاقی مرتبط با شی Auth بیفتد مطلع می شود. به مدیریت کاربران ( iOS ، Android ، وب ) مراجعه کنید.
شنونده Auth در شرایط زیر مطلع می شود:
- شیء Auth مقداردهی اولیه را تمام می کند و یک کاربر قبلاً از جلسه قبلی وارد سیستم شده است یا از جریان ورود به سیستم ارائه دهنده هویت هدایت شده است.
- یک کاربر وارد سیستم می شود (کاربر فعلی تنظیم شده است)
- یک کاربر از سیستم خارج می شود (کاربر فعلی پوچ می شود)
- رمز دسترسی کاربر فعلی به روز شده است. این مورد می تواند در شرایط زیر رخ دهد:
- نشانه دسترسی منقضی می شود: این یک وضعیت رایج است. نشانه رفرش برای به دست آوردن مجموعه ای معتبر از توکن ها استفاده می شود.
- کاربر رمز عبور خود را تغییر می‌دهد: Firebase توکن‌های دسترسی جدید و تازه‌سازی را صادر می‌کند و توکن‌های قدیمی را منقضی می‌کند. این به دلایل امنیتی به طور خودکار توکن کاربر را منقضی می کند و/یا کاربر را در هر دستگاهی از سیستم خارج می کند.
- کاربر احراز هویت مجدد: برخی از اقدامات مستلزم آن است که اعتبار کاربر اخیراً صادر شده باشد. چنین اقداماتی شامل حذف یک حساب کاربری، تنظیم یک آدرس ایمیل اصلی و تغییر رمز عبور است. به جای خروج از سیستم کاربر و سپس ورود مجدد به کاربر، اعتبارنامه های جدید را از کاربر دریافت کنید و اعتبار جدید را به روش احراز هویت مجدد شی کاربر منتقل کنید.
سلف سرویس کاربر
به‌طور پیش‌فرض، Firebase به کاربران امکان می‌دهد بدون مداخله مدیریت ثبت‌نام و حساب‌های خود را حذف کنند. در بسیاری از شرایط، این به کاربران نهایی این امکان را می‌دهد تا اپلیکیشن یا سرویس شما را پیدا کنند و با کمترین اصطکاک در داخل (یا خارج از کشتی) باشند.
با این حال، موقعیت‌هایی وجود دارد که می‌خواهید کاربران به‌صورت دستی یا برنامه‌ریزی شده توسط یک سرپرست، با استفاده از Admin SDK یا کنسول Firebase ایجاد شوند. در این موارد، می‌توانید اقدامات کاربر را از صفحه تنظیمات Firebase Authentication غیرفعال کنید، که از ایجاد و حذف حساب توسط کاربران نهایی جلوگیری می‌کند. اگر از چند اجاره استفاده می کنید، باید یک درخواست HTTP برای غیرفعال کردن این ویژگی ها به ازای هر مستاجر ارائه دهید.
اگر کاربر نهایی بخواهد یک حساب در سیستم شما ایجاد یا حذف کند، سرویس Firebase یک کد خطا را برمی‌گرداند: auth/admin-restricted-operation برای تماس‌های Web API، یا ERROR_ADMIN_RESTRICTED_OPERATION برای Android و iOS. شما باید با ظرافت با این خطا در قسمت جلویی خود از کاربر بخواهید که اقدامات مناسب را برای خدمات شما انجام دهد.
توکن‌های احراز هویت
هنگامی که احراز هویت را با Firebase انجام می دهید، ممکن است با سه نوع نشانه احراز هویت روبرو شوید:
| توکن های Firebase ID | هنگامی که کاربر وارد برنامه ای می شود توسط Firebase ایجاد می شود. این توکن ها JWT های امضا شده ای هستند که به طور ایمن کاربر را در پروژه Firebase شناسایی می کنند. این توکن ها حاوی اطلاعات اولیه نمایه یک کاربر، از جمله رشته ID کاربر است که منحصر به پروژه Firebase است. از آنجایی که یکپارچگی نشانه‌های شناسه قابل تأیید است ، می‌توانید آنها را به یک سرور پشتیبان ارسال کنید تا کاربر وارد شده فعلی را شناسایی کند. |
| توکن های ارائه دهنده هویت | ایجاد شده توسط ارائه دهندگان هویت فدرال، مانند گوگل و فیس بوک. این توکن ها می توانند فرمت های مختلفی داشته باشند، اما اغلب نشانه های دسترسی OAuth 2.0 هستند. برنامه‌ها از این نشانه‌ها استفاده می‌کنند تا تأیید کنند که کاربران با ارائه‌دهنده هویت با موفقیت احراز هویت شده‌اند و سپس آنها را به اعتبارنامه‌های قابل استفاده توسط سرویس‌های Firebase تبدیل می‌کنند. |
| توکن های سفارشی Firebase | توسط سیستم احراز هویت سفارشی شما ایجاد شده است تا به کاربران اجازه دهد با استفاده از سیستم احراز هویت شما به برنامه وارد شوند. توکن های سفارشی JWT هایی هستند که با استفاده از کلید خصوصی حساب سرویس امضا شده اند . برنامه‌ها از این توکن‌ها استفاده می‌کنند، دقیقاً مانند رمزهایی که از ارائه‌دهندگان هویت فدرال بازگردانده شده‌اند. |
آدرس های ایمیل تایید شده
Firebase یک ایمیل را در صورت داشتن دو شرط تأیید شده در نظر می گیرد:
- کاربر جریان تأیید Firebase را تکمیل می کند
- ایمیل توسط یک Identity Provider یا به اختصار IdP تأیید می شود.
IdPهایی که یک بار ایمیل را تأیید می کنند، اما به کاربران اجازه می دهند آدرس ایمیل را بدون نیاز به تأیید مجدد تغییر دهند، قابل اعتماد نیستند. IdPهایی که یا مالک دامنه هستند یا همیشه نیاز به تأیید دارند، قابل اعتماد در نظر گرفته می شوند.
ارائه دهندگان مورد اعتماد:
- Google (برای آدرس‌های @gmail.com)
- یاهو (برای آدرس های @yahoo.com)
- مایکروسافت (برای آدرس های @outlook.com و @hotmail.com)
- اپل (همیشه تأیید می شود، زیرا حساب ها همیشه تأیید شده و احراز هویت چند عاملی هستند)
ارائه دهندگان غیر قابل اعتماد:
- فیس بوک
- توییتر
- GitHub
- Google، Yahoo و Microsoft برای دامنه‌هایی که توسط آن ارائه‌دهنده هویت صادر نشده‌اند
- ایمیل / رمز عبور بدون تایید ایمیل
در برخی شرایط، هنگامی که کاربر با استفاده از آدرس ایمیل یکسان با ارائه دهندگان مختلف وارد می شود، Firebase به طور خودکار حساب ها را پیوند می دهد. با این حال، این تنها زمانی اتفاق می افتد که معیارهای خاصی رعایت شود. برای درک دلیل، وضعیت زیر را در نظر بگیرید: یک کاربر با استفاده از Google با یک حساب @gmail.com وارد سیستم می شود و یک عامل مخرب با استفاده از همان آدرس @gmail.com یک حساب ایجاد می کند، اما از طریق فیس بوک وارد می شود. اگر این دو حساب به طور خودکار به هم مرتبط شوند، عامل مخرب به حساب کاربر دسترسی پیدا می کند.
موارد زیر زمانی را توصیف می‌کنند که ما به‌طور خودکار حساب‌ها را پیوند می‌دهیم و زمانی که خطای مورد نیاز کاربر یا برنامه‌نویس را انجام می‌دهیم:
- کاربر با یک ارائه‌دهنده نامعتبر وارد سیستم می‌شود، سپس با همان ایمیل با ارائه‌دهنده غیرقابل اعتماد دیگری وارد می‌شود (مثلاً فیس‌بوک و سپس GitHub). این یک خطا را ایجاد می کند که نیاز به پیوند دادن حساب دارد.
- کاربر با یک ارائه‌دهنده مورد اعتماد وارد سیستم می‌شود، سپس با همان ایمیل با ارائه‌دهنده غیرقابل اعتماد وارد می‌شود (مثلاً گوگل به دنبال آن فیس‌بوک). این یک خطا را ایجاد می کند که نیاز به پیوند دادن حساب دارد.
- کاربر با یک ارائه‌دهنده نامعتبر وارد سیستم می‌شود، سپس با همان ایمیل با یک ارائه‌دهنده مورد اعتماد وارد می‌شود (مثلاً فیس‌بوک و سپس گوگل). ارائه دهنده مورد اعتماد، ارائه دهنده نامعتبر را بازنویسی می کند. اگر کاربر سعی کند دوباره با فیس بوک وارد شود، خطای نیاز به پیوند حساب ایجاد می کند.
- کاربر با یک ارائه‌دهنده مورد اعتماد وارد سیستم می‌شود، سپس با همان ایمیل با یک ارائه‌دهنده مورد اعتماد دیگر وارد سیستم می‌شود (مثلاً اپل و پس از آن Google). هر دو ارائه دهنده بدون خطا پیوند داده می شوند.
با استفاده از Admin SDK می‌توانید به صورت دستی یک ایمیل را به‌عنوان تأیید شده تنظیم کنید، اما توصیه می‌کنیم فقط در صورتی این کار را انجام دهید که بدانید کاربر واقعاً مالک ایمیل است.