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