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