بهترین روش‌ها برای استفاده از signInWithRedirect در مرورگرهایی که دسترسی به ذخیره‌سازی شخص ثالث را مسدود می‌کنند
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
این سند بهترین روش‌ها را برای استفاده از تغییر مسیر در مرورگرهایی که کوکی‌های شخص ثالث را مسدود می‌کنند، توضیح می‌دهد. شما باید یکی از گزینه های فهرست شده در اینجا را دنبال کنید تا signInWithRedirect() تا در محیط های تولیدی در همه مرورگرها عمل کند.
نمای کلی
برای اینکه جریان signInWithRedirect() برای شما و کاربرانتان یکپارچه باشد، Firebase Authentication JavaScript SDK از یک iframe با مبدا متقاطع استفاده می کند که به دامنه میزبانی Firebase برنامه شما متصل می شود. با این حال، این مکانیسم با مرورگرهایی که دسترسی به ذخیره سازی شخص ثالث را مسدود می کنند، کار نمی کند.
از آنجا که درخواست از کاربران خود برای غیرفعال کردن ویژگی های پارتیشن بندی فضای ذخیره سازی در مرورگر به ندرت گزینه ای است، در عوض باید یکی از گزینه های راه اندازی زیر را بسته به ویژگی های مورد استفاده خود در برنامه خود اعمال کنید.
اگر برنامه خود را با میزبانی Firebase در زیر دامنه firebaseapp.com میزبانی می کنید، تحت تأثیر این مشکل قرار نگرفته اید و نیازی به اقدامی نیست.
اگر برنامه خود را با میزبانی Firebase در یک دامنه سفارشی یا یک زیر دامنه web.app میزبانی می کنید، از گزینه 1 استفاده کنید.
اگر برنامه خود را با سرویسی غیر از Firebase میزبانی می کنید، از گزینه 2 ، گزینه 3 ، گزینه 4 یا گزینه 5 استفاده کنید.
گزینه 1: پیکربندی Firebase خود را برای استفاده از دامنه سفارشی خود به عنوان authDomain خود به روز کنید
اگر برنامه خود را با میزبانی Firebase با استفاده از یک دامنه سفارشی میزبانی می کنید، می توانید Firebase SDK را برای استفاده از دامنه سفارشی خود به عنوان authDomain پیکربندی کنید. این تضمین می کند که برنامه شما و iframe auth از یک دامنه استفاده می کنند، که از مشکل ورود به سیستم جلوگیری می کند. (اگر از هاست Firebase استفاده نمی کنید، باید از گزینه دیگری استفاده کنید.). مطمئن شوید که دامنه سفارشی را در همان پروژه ای که برای احراز هویت استفاده می کنید راه اندازی کرده اید.
برای به‌روزرسانی پیکربندی Firebase برای استفاده از دامنه سفارشی به عنوان دامنه تأیید اعتبار، موارد زیر را انجام دهید:
Firebase JS SDK را برای استفاده از دامنه سفارشی خود به عنوان authDomain پیکربندی کنید:
authDomain جدید را به لیست URIهای مجاز تغییر مسیر ارائه دهنده OAuth خود اضافه کنید. نحوه انجام این کار به ارائه دهنده بستگی دارد، اما به طور کلی می توانید برای دستورالعمل های دقیق (مثلاً ارائه دهنده فیس بوک ) بخش «قبل از شروع» را در هر ارائه دهنده ای دنبال کنید. URI به‌روزرسانی‌شده برای تأیید به‌نظر می‌رسد https://<the-domain-that-serves-your-app>/__/auth/handler - /__/auth/handler آخر مهم است.
به طور مشابه، اگر از یک ارائه‌دهنده SAML استفاده می‌کنید، authDomain جدید را به URL SAML Assertion Consumer Service (ACS) اضافه کنید.
مطمئن شوید continue_uri شما در لیست دامنه های مجاز قرار دارد.
در صورت نیاز برای واکشی به روزترین فایل پیکربندی Firebase که در /__/firebase/init.json میزبانی شده است، مجدداً با میزبانی Firebase مستقر شوید.
گزینه 2: به signInWithPopup () بروید
از signInWithPopup() به جای signInWithRedirect() استفاده کنید. بقیه کد برنامه شما یکسان باقی می ماند، اما شی UserCredential به طور متفاوتی بازیابی می شود.
Web
// Before// ==============signInWithRedirect(auth,newGoogleAuthProvider());// After the page redirects backconstuserCred=awaitgetRedirectResult(auth);// After// ==============constuserCred=awaitsignInWithPopup(auth,newGoogleAuthProvider());
Web
// Before// ==============firebase.auth().signInWithRedirect(newfirebase.auth.GoogleAuthProvider());// After the page redirects backvaruserCred=awaitfirebase.auth().getRedirectResult();// After// ==============varuserCred=awaitfirebase.auth().signInWithPopup(newfirebase.auth.GoogleAuthProvider());```
ورود به سیستم بازشو همیشه برای کاربران ایده‌آل نیست - پنجره‌های بازشو گهگاه توسط دستگاه یا پلتفرم مسدود می‌شوند و جریان برای کاربران تلفن همراه کمتر روان است. اگر استفاده از پنجره‌های بازشو برای برنامه شما مشکل است، باید یکی از گزینه‌های دیگر را دنبال کنید.
گزینه 3: درخواست های احراز هویت پروکسی به firebaseapp.com
جریان signInWithRedirect با هدایت مجدد از دامنه برنامه شما به دامنه مشخص شده در پارامتر authDomain در پیکربندی firebase (" .firebaseapp.com" به طور پیش‌فرض). authDomain میزبان کد کمکی ورود به سیستم است که به Identity Provider هدایت می‌شود، که در صورت موفقیت، دوباره به دامنه برنامه هدایت می‌شود.
هنگامی که جریان احراز هویت به دامنه برنامه شما باز می گردد، به ذخیره سازی مرورگر دامنه کمکی ورود به سیستم دسترسی پیدا می کند. این گزینه و گزینه بعدی (برای میزبانی خودکار کد) دسترسی به فضای ذخیره سازی متقاطع را حذف می کند، که در غیر این صورت توسط مرورگرها مسدود می شود.
یک پروکسی معکوس در سرور برنامه خود تنظیم کنید تا درخواست های GET/POST به https://<app domain>/__/auth/ به https://<project>.firebaseapp.com/__/auth/ ارسال شود. اطمینان حاصل کنید که این ارسال به مرورگر شفاف است. این را نمی توان از طریق تغییر مسیر 302 انجام داد.
اگر از nginx برای ارائه دامنه سفارشی خود استفاده می کنید، پیکربندی معکوس پروکسی به این صورت خواهد بود:
# reverse proxy for signin-helpers for popup/redirect sign in.
location/__/auth{proxy_passhttps://<project>.firebaseapp.com;}
مراحل گزینه 1 را برای به روز رسانی مجاز redirect_uri ، URL ACS و authDomain خود دنبال کنید. هنگامی که برنامه خود را مجدداً راه اندازی کردید، دسترسی به فضای ذخیره سازی متقاطع دیگر نباید اتفاق بیفتد.
گزینه 4: کد کمکی ورود به سیستم را در دامنه خود میزبانی کنید
راه دیگر برای حذف دسترسی به فضای ذخیره‌سازی متقاطع، میزبانی خودکار کد کمکی ورود به سیستم Firebase است. با این حال، این رویکرد برای ورود به سیستم اپل یا SAML کار نمی کند. فقط در صورتی از این گزینه استفاده کنید که راه اندازی معکوس پروکسی در گزینه 3 غیر ممکن باشد.
میزبانی کد کمکی مراحل زیر را دارد:
با اجرای دستورات زیر فایل ها را برای میزبانی از مکان <project>.firebaseapp.com دانلود کنید:
فایل های بالا را در دامنه برنامه خود میزبانی کنید. مطمئن شوید که سرور وب شما می تواند به https://<app domain>/__/auth/<filename> و https://<app domain>/__/firebase/init.json پاسخ دهد.
در اینجا یک نمونه اجرای سرور است که فایل ها را دانلود و میزبانی می کند. توصیه می‌کنیم فایل‌ها را به صورت دوره‌ای دانلود و همگام‌سازی کنید تا مطمئن شوید که آخرین رفع اشکال و ویژگی‌ها انتخاب شده‌اند.
مراحل گزینه 1 را برای به روز رسانی مجاز redirect_uri و authDomain خود دنبال کنید. هنگامی که برنامه خود را مجدداً راه اندازی کردید، دسترسی به فضای ذخیره سازی متقاطع دیگر نباید اتفاق بیفتد.
گزینه 5: ورود به سیستم ارائه دهنده را به طور مستقل مدیریت کنید
Firebase Authentication SDK signInWithPopup() و signInWithRedirect() را به عنوان روش‌های راحت برای پیچیده کردن منطق پیچیده و اجتناب از نیاز به درگیر کردن SDK دیگر ارائه می‌کند. می‌توانید با ورود مستقل به ارائه‌دهنده خود، و سپس با استفاده از signInWithCredential() برای مبادله اعتبار ارائه‌دهنده با اعتبار Firebase Authentication، از استفاده از هر یک از روش‌ها به طور کامل اجتناب کنید. برای مثال، می‌توانید از Google Sign In SDK ، کد نمونه برای دریافت اعتبار حساب Google استفاده کنید، سپس با اجرای کد زیر، یک اعتبار جدید Google را نمونه‌سازی کنید:
Web
// `googleUser` from the onsuccess Google Sign In callback.// googUser = gapi.auth2.getAuthInstance().currentUser.get();constcredential=GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);constresult=awaitsignInWithCredential(auth,credential);
Web
// `googleUser` from the onsuccess Google Sign In callback.constcredential=firebase.auth.GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);constresult=awaitfirebase.auth().signInWithCredential(credential);
بعد از اینکه signInWithCredential() را فراخوانی کردید، بقیه برنامه شما مانند قبل عمل می کند.
تاریخ آخرین به‌روزرسانی 2025-08-30 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین به‌روزرسانی 2025-08-30 بهوقت ساعت هماهنگ جهانی."],[],[],null,["This document describes the best practices for using redirect sign-ins on browsers\nthat block third-party cookies. You must follow one of the options listed here for [`signInWithRedirect()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithredirect) to function as intended in production environments, across all browsers.\n| **Note:** Starting June 24 2024, implementing one of the options will be required for redirect sign-in to work on Google Chrome M115+. This is already required on Firefox 109+ and Safari 16.1+.\n\nOverview\n\nTo make the\n[`signInWithRedirect()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithredirect) flow\nseamless for you and your users, the Firebase Authentication JavaScript SDK uses a\ncross-origin iframe that connects to your app's Firebase Hosting domain.\nHowever, this mechanism doesn't work with browsers that block third-party\nstorage access.\n\nBecause asking your users to disable storage partitioning features on the browser is rarely an option, you should instead apply one of the following setup options to your app, depending on the specifics of your use case.\n\n- If you host your app with Firebase Hosting on a subdomain of `firebaseapp.com`, you are not affected by this issue and no action is needed.\n- If you host your app with Firebase Hosting on a custom domain or a subdomain of `web.app`, use [Option 1](#update-authdomain).\n- If you host your app with a service other than Firebase, use [Option 2](#signinwithpopup), [Option 3](#proxy-requests), [Option 4](#self-host-helper-code), or [Option 5](#handle-signin-independently).\n\nOption 1: Update your Firebase config to use your custom domain as your `authDomain`\n\nIf you're hosting your app with Firebase Hosting using a custom domain, you can\nconfigure the Firebase SDK to use your custom domain as the `authDomain`. This\nensures that your app and the auth iframe use the same domain, which prevents\nthe sign-in issue. (If you don't use Firebase Hosting, you need to use a\ndifferent option.). Make sure you've set up the custom domain on the same\nproject you are using for authentication.\n\nTo update your Firebase config to use your custom domain as your auth domain, do\nthe following:\n\n1. Configure the Firebase JS SDK to use your custom domain as the `authDomain`:\n\n const firebaseConfig = {\n apiKey: \"\u003capi-key\u003e\",\n authDomain: \"\u003cthe-domain-that-serves-your-app\u003e\",\n databaseURL: \"\u003cdatabase-url\u003e\",\n projectId: \"\u003cproject-id\u003e\",\n appId: \"\u003capp-id\u003e\"\n };\n\n| **Important:** Normally, you should not modify any other field in the Firebase config object. [Learn about the Firebase config object](/docs/web/learn-more#config-object).\n\n1. Add the new `authDomain` to your OAuth provider's list of authorized\n redirect URIs. How you do this will depend on the provider, but in general\n you can follow the \"Before you begin\" section in any provider for exact\n instructions (for example, the\n [Facebook provider](https://firebase.google.com/docs/auth/web/facebook-login)). The updated URI to\n authorize looks like\n `https://\u003cthe-domain-that-serves-your-app\u003e/__/auth/handler` --- the trailing\n `/__/auth/handler` is important.\n\n Similarly, if you're using a SAML provider, add the new `authDomain` to the\n SAML Assertion Consumer Service (ACS) URL.\n2. Make sure your `continue_uri` is in the list of [authorized domains](https://console.firebase.google.com/project/_/authentication/settings).\n\n3. Re-deploy with Firebase Hosting if needed to fetch the most up-to-date Firebase configuration file hosted at `/__/firebase/init.json`.\n\nOption 2: Switch to signInWithPopup()\n\nUse [`signInWithPopup()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithpopup) instead of\n[`signInWithRedirect()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithredirect). The\nrest of your app's code remains the same, but the UserCredential object is\nretrieved differently. \n\nWeb \n\n // Before\n // ==============\n signInWithRedirect(auth, new GoogleAuthProvider());\n // After the page redirects back\n const userCred = await getRedirectResult(auth);\n\n // After\n // ==============\n const userCred = await signInWithPopup(auth, new GoogleAuthProvider());\n\nWeb \n\n // Before\n // ==============\n firebase.auth().signInWithRedirect(new firebase.auth.GoogleAuthProvider());\n // After the page redirects back\n var userCred = await firebase.auth().getRedirectResult();\n\n // After\n // ==============\n var userCred = await firebase.auth().signInWithPopup(\n new firebase.auth.GoogleAuthProvider());\n ```\n\nPopup sign-in isn't always ideal for users---popups are occasionally blocked by\nthe device or platform, and the flow is less smooth for mobile users. If using\npopups is an issue for your app, you'll need to follow one of the other\noptions.\n\nOption 3: Proxy auth requests to firebaseapp.com\n\nThe `signInWithRedirect` flow starts by redirecting from your app domain to the\ndomain specified in the `authDomain` parameter in firebase config\n(\".firebaseapp.com\" by default). `authDomain` hosts the sign-in helper code that redirects to the Identity Provider, which, on success, redirects back to the app domain.\n\nWhen the authentication flow returns to your app domain, the browser storage of\nthe sign-in helper domain is accessed. This option and the\nfollowing one (to self-host the code) eliminates the cross-origin storage access, which otherwise gets blocked by browsers.\n\n1. Set up a reverse proxy on your app server so that GET/POST requests to\n `https://\u003capp domain\u003e/__/auth/` are forwarded to `https://\u003cproject\u003e.firebaseapp.com/__/auth/`.\n Ensure that this forwarding is transparent to the browser; this cannot be done via a 302 Redirect.\n\n If you are using nginx to serve your custom domain, the reverse-proxy config will look like this: \n\n # reverse proxy for signin-helpers for popup/redirect sign in.\n location /__/auth {\n proxy_pass https://\u003cproject\u003e.firebaseapp.com;\n }\n\n2. Follow the steps in\n [Option 1](#update-authdomain)\n to update authorized `redirect_uri`, ACS URL and your `authDomain`. Once you re-deploy\n your app, the cross-origin storage access should no longer happen.\n\nOption 4: Self-host the sign-in helper code in your domain\n\nAnother way to eliminate the cross-origin storage access is to self-host\nthe Firebase sign-in helper code. However, this approach doesn't work for Apple\nsign-in or SAML. Use this option only if the reverse-proxy setup in\noption 3 is infeasible.\n\nHosting the helper code has the following steps:\n\n1. Download the files to host from the `\u003cproject\u003e.firebaseapp.com` location by\n executing the following commands:\n\n mkdir signin_helpers/ && cd signin_helpers\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/handler\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/handler.js\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/experiments.js\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/iframe\n wget https://\u003cproject\u003e.firebaseapp.com/__/auth/iframe.js\n wget https://\u003cproject\u003e.firebaseapp.com/__/firebase/init.json\n\n2. Host the above files under your app domain. Ensure that your web server\n can respond to `https://\u003capp domain\u003e/__/auth/\u003cfilename\u003e` and\n `https://\u003capp domain\u003e/__/firebase/init.json`.\n\n Here is a [sample server implementation](https://go.dev/play/p/yvHmY9Bd50N) that downloads and hosts the files.\n We recommend downloading and syncing the files periodically to ensure that the latest bug fixes and features are picked up.\n3. Follow the steps in\n [Option 1](#update-authdomain)\n to update authorized `redirect_uri` and your `authDomain`. Once you re-deploy\n your app, the cross-origin storage access should no longer happen.\n\nOption 5: Handle provider sign-in independently **Important:** This is a complex approach that uses additional SDKs, and potentially can be very involved for SAML providers.\n\nThe Firebase Authentication SDK provides\n[`signInWithPopup()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithpopup) and\n[`signInWithRedirect()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithredirect) as\nconvenience methods to wrap complicated logic and avoid the need to involve\nanother SDK. You can avoid using either method entirely by independently signing\nin to your provider, then using\n[`signInWithCredential()`](https://firebase.google.com/docs/reference/js/auth.md#signinwithcredential) to\nexchange the provider's credentials for a Firebase Authentication credential.\nFor example, you can use the\n[Google Sign In SDK](https://developers.google.com/identity/gsi/web/guides/overview),\n[sample code](https://github.com/google/google-api-javascript-client/blob/master/samples/authSample.html)\nto obtain a Google account credential, then instantiate a new Google credential,\nby running the following code: \n\nWeb \n\n // `googleUser` from the onsuccess Google Sign In callback.\n // googUser = gapi.auth2.getAuthInstance().currentUser.get();\n const credential = GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);\n const result = await signInWithCredential(auth, credential);\n\nWeb \n\n // `googleUser` from the onsuccess Google Sign In callback.\n const credential = firebase.auth.GoogleAuthProvider.credential(\n googleUser.getAuthResponse().id_token);\n const result = await firebase.auth().signInWithCredential(credential);\n\nAfter you've called `signInWithCredential()`, the rest of your app functions the\nsame as it did before.\n\nInstructions for obtaining an Apple credential are\n[here](https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/configuring_your_webpage_for_sign_in_with_apple)."]]
