این سند روال‌های مطلوب استفاده از ورود به سیستم با هدایت مجدد در مرورگرهایی را که کوکی‌های طرف سوم را مسدود می‌کنند شرح می‌دهد. برای اینکه signInWithRedirect() در محیط‌های تولید و در همه مرورگرها طبق انتظار عمل کند، باید یکی از گزینه‌های فهرست‌شده در اینجا را دنبال کنید.
نمای کلی
برای اینکه جریان
signInWithRedirect()
برای شما و کاربران‌تان یکپارچه باشد، «کیت توسعه نرم‌افزار جاوااسکریپت Firebase Authentication» از
iframe بین مبدأ استفاده می‌کند که به دامنه Firebase Hosting برنامه‌تان متصل می‌شود.
بااین‌حال، این سازوکار با مرورگرهایی که دسترسی به فضای ذخیره‌سازی طرف سوم را مسدود می‌کنند کار نمی‌کند.
ازآنجایی‌که درخواست از کاربران برای غیرفعال کردن ویژگی‌های پارتیشن‌بندی فضای ذخیره‌سازی در مرورگر به‌ندرت گزینه مناسبی است، باید بسته به جزئیات مورد استفاده‌تان، یکی از گزینه‌های راه‌اندازی زیر را برای برنامه‌تان اعمال کنید.
- اگر برنامه خود را با «میزبانی Firebase» در زیردامنه‌ای از
firebaseapp.comمیزبانی می‌کنید، تحت تأثیر این مشکل قرار نمی‌گیرید و نیازی به اقدام نیست. - اگر برنامه‌تان را با «میزبانی Firebase» در دامنه سفارشی یا زیردامنه
web.appمیزبانی می‌کنید، از گزینه ۱ استفاده کنید. - اگر برنامه‌تان را با سرویسی غیر از Firebase میزبانی می‌کنید، از گزینه ۲، گزینه ۳، گزینه ۴، یا گزینه ۵ استفاده کنید.
گزینه ۱: پیکربندی Firebase را به‌روز کنید تا از دامنه سفارشی‌تان به‌عنوان authDomain استفاده کنید
اگر برنامه‌تان را بااستفاده از دامنه سفارشی با «میزبانی Firebase» میزبانی می‌کنید، می‌توانید «کیت توسعه نرم‌افزار Firebase» را پیکربندی کنید تا از دامنه سفارشی‌تان به‌عنوان authDomain استفاده کند. این کار تضمین می‌کند که برنامه شما و iframe اصالت‌سنجی از دامنه یکسانی استفاده کنند، که از مشکل ورود به سیستم جلوگیری می‌کند. (اگر از «میزبانی Firebase» استفاده نمی‌کنید، باید از گزینه دیگری استفاده کنید.). مطمئن شوید که دامنه سفارشی را در همان
پروژه‌ای که برای اصالت‌سنجی استفاده می‌کنید راه‌اندازی کرده‌اید.
برای به‌روز کردن پیکربندی Firebase به‌منظور استفاده از دامنه سفارشی به‌عنوان دامنه اصالت‌سنجی، کارهای زیر را انجام دهید:
«کیت توسعه نرم‌افزار Firebase JS» را پیکربندی کنید تا از دامنه سفارشی‌تان به‌عنوان
authDomainاستفاده کند:const firebaseConfig = { apiKey: "<api-key>", authDomain: "<the-domain-that-serves-your-app>", databaseURL: "<database-url>", projectId: "<project-id>", appId: "<app-id>" };
authDomainجدید را به فهرست شناسه‌های «URI هدایت» مجاز ارائه‌دهنده OAuth خود اضافه کنید. نحوه انجام این کار به ارائه‌دهنده بستگی دارد، اما به‌طورکلی می‌توانید بخش «قبل‌از شروع» را در هر ارائه‌دهنده برای دستورالعمل‌های دقیق دنبال کنید (برای مثال، ارائه‌دهنده Facebook). نشانی وب به‌روزشده برای مجوز دادن به‌صورتhttps://<the-domain-that-serves-your-app>/__/auth/handlerاست —/__/auth/handlerدر انتها مهم است.به‌همین ترتیب، اگر از ارائه‌دهنده SAML استفاده می‌کنید،
authDomainجدید را به نشانی وب «سرویس مصرف‌کننده ادعای SAML» (ACS) اضافه کنید.مطمئن شوید که
continue_uriشما در فهرست دامنه‌های مجاز قرار دارد.درصورت نیاز، با «میزبانی Firebase» مجدداً مستقر کنید تا جدیدترین فایل پیکربندی Firebase میزبانی‌شده در
/__/firebase/init.jsonرا واکشی کنید.
گزینه ۲: رفتن به signInWithPopup()
به‌جای signInWithRedirect() از signInWithPopup() استفاده کنید. بقیه کد برنامه شما یکسان باقی می‌ماند، اما شیء UserCredential به‌روش دیگری بازیابی می‌شود.
Web
// Before
// ==============
signInWithRedirect(auth, new GoogleAuthProvider());
// After the page redirects back
const userCred = await getRedirectResult(auth);
// After
// ==============
const userCred = await signInWithPopup(auth, new GoogleAuthProvider());
Web
// Before
// ==============
firebase.auth().signInWithRedirect(new firebase.auth.GoogleAuthProvider());
// After the page redirects back
var userCred = await firebase.auth().getRedirectResult();
// After
// ==============
var userCred = await firebase.auth().signInWithPopup(
new firebase.auth.GoogleAuthProvider());
```
ورود به سیستم با بالاپَر همیشه برای کاربران ایده‌آل نیست—بالاپَرها گاهی‌اوقات توسط دستگاه یا پلاتفرم مسدود می‌شوند و جریان برای کاربران تلفن همراه روان‌تر است. اگر استفاده از بالاپَرها برای برنامه‌تان مشکل‌ساز است، باید یکی از گزینه‌های دیگر را دنبال کنید.
گزینه ۳: درخواست‌های اصالت‌سنجی پراکسی به firebaseapp.com
جریان signInWithRedirect با هدایت مجدد از دامنه برنامه شما به دامنه مشخص‌شده در پارامتر authDomain در پیکربندی Firebase شروع می‌شود
(به‌طور پیش‌فرض «authDomain میزبان کد دستیار ورود به سیستم است که به «ارائه‌دهنده هویت» هدایت می‌کند و درصورت موفقیت، به دامنه برنامه هدایت می‌کند.
وقتی جریان اصالت‌سنجی به دامنه برنامه شما برمی‌گردد، به فضای ذخیره‌سازی مرورگر دامنه یاری‌رسان ورود به سیستم دسترسی پیدا می‌شود. این گزینه و گزینه زیر (برای میزبانی خودکار کد) دسترسی به فضای ذخیره‌سازی بین‌مبدائی را که درغیراین‌صورت توسط مرورگرها مسدود می‌شود حذف می‌کند.
کارگزار جانشین معکوسی در سرور برنامه‌تان راه‌اندازی کنید تا درخواست‌های GET/POST به
https://<app domain>/__/auth/بهhttps://<project>.firebaseapp.com/__/auth/بازارسال شود. مطمئن شوید که این بازارسال برای مرورگر شفاف باشد؛ این کار را نمی‌توان ازطریق «بازارسال ۳۰۲» انجام داد.اگر از nginx برای ارائه دامنه سفارشی خود استفاده می‌کنید، پیکربندی پروکسی معکوس به این شکل خواهد بود:
# reverse proxy for signin-helpers for popup/redirect sign in. location /__/auth { proxy_pass https://<project>.firebaseapp.com; }برای به‌روزرسانی
redirect_uriمجاز، نشانی وب ACS، وauthDomain، مراحل گزینه ۱ را دنبال کنید. پس‌از استقرار مجدد برنامه، دسترسی به فضای ذخیره‌سازی بین مبدأ دیگر نباید اتفاق بیفتد.
گزینه ۴: میزبانی کد کمکی ورود به سیستم در دامنه خودتان
روش دیگر برای حذف دسترسی به فضای ذخیره‌سازی بین مبدأها این است که کد دستیار ورود به سیستم Firebase را خودتان میزبانی کنید. بااین‌حال، این رویکرد برای ورود به سیستم Apple یا SAML کار نمی‌کند. فقط درصورتی از این گزینه استفاده کنید که راه‌اندازی پراکسی معکوس در گزینه ۳ غیرممکن باشد.
مراحل میزبانی کد کمکی به شرح زیر است:
با اجرای فرمان‌های زیر، فایل‌ها را از مکان
<project>.firebaseapp.comبارگیری کنید تا میزبانی کنید:mkdir signin_helpers/ && cd signin_helpers wget https://<project>.firebaseapp.com/__/auth/handler wget https://<project>.firebaseapp.com/__/auth/handler.js wget https://<project>.firebaseapp.com/__/auth/experiments.js wget https://<project>.firebaseapp.com/__/auth/iframe wget https://<project>.firebaseapp.com/__/auth/iframe.js wget https://<project>.firebaseapp.com/__/auth/links wget https://<project>.firebaseapp.com/__/auth/links.js wget https://<project>.firebaseapp.com/__/firebase/init.jsonفایل‌های بالا را در دامنه برنامه‌تان میزبانی کنید. مطمئن شوید که سرور وب شما می‌تواند به
https://<app domain>/__/auth/<filename>وhttps://<app domain>/__/firebase/init.jsonپاسخ دهد.در اینجا پیاده‌سازی سرور نمونه‌ای وجود دارد که فایل‌ها را بارگیری و میزبانی می‌کند. توصیه می‌کنیم فایل‌ها را به‌صورت دوره‌ای بارگیری و همگام‌سازی کنید تا مطمئن شوید که جدیدترین رفع اشکالات و ویژگی‌ها را دریافت می‌کنید.
مراحل گزینه ۱ را برای به‌روزرسانی
redirect_uriمجاز وauthDomainخود دنبال کنید. پس‌از استقرار مجدد برنامه، دسترسی به فضای ذخیره‌سازی بین مبدأ دیگر نباید اتفاق بیفتد.
گزینه ۵: ورود به سیستم ارائه‌دهنده را به‌طور مستقل مدیریت کنید
«کیت توسعه نرم‌افزار Firebase Authentication»
signInWithPopup() و
signInWithRedirect() را به‌عنوان
روش‌های راحت برای پوشش دادن منطق پیچیده و اجتناب از نیاز به استفاده از
کیت توسعه نرم‌افزار دیگر ارائه می‌دهد. می‌توانید با ورود به سیستم ارائه‌دهنده به‌طور مستقل و سپس استفاده از signInWithCredential() برای تبدیل اعتبارنامه ارائه‌دهنده به اعتبارنامه «اصالت‌سنجی Firebase»، به‌طور کامل از هر دو روش استفاده نکنید.
برای مثال، می‌توانید از
کیت توسعه نرم‌افزار ورود به سیستم Google،
کد نمونه
برای دریافت اطلاعات اعتباری حساب Google استفاده کنید، سپس با اجرای کد زیر، اطلاعات اعتباری Google جدیدی را نمونه‌سازی کنید:
Web
// `googleUser` from the onsuccess Google Sign In callback.
// googUser = gapi.auth2.getAuthInstance().currentUser.get();
const credential = GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);
const result = await signInWithCredential(auth, credential);
Web
// `googleUser` from the onsuccess Google Sign In callback.
const credential = firebase.auth.GoogleAuthProvider.credential(
googleUser.getAuthResponse().id_token);
const result = await firebase.auth().signInWithCredential(credential);
پس‌از تماس با signInWithCredential()، بقیه عملکردهای برنامه شما
همان‌طور که قبلاً بود کار می‌کند.
دستورالعمل‌های دریافت اطلاعات اعتباری Apple در اینجا موجود است.