أفضل الممارسات لاستخدام ميزةsignInWithRedirect في المتصفّحات التي تحظر إمكانية الوصول إلى مساحة تخزين الجهات الخارجية
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يصف هذا المستند أفضل الممارسات لاستخدام عمليات تسجيل الدخول من خلال عمليات إعادة التوجيه على المتصفّحات.
تحظر ملفات تعريف الارتباط التابعة لجهات خارجية يجب اتّباع أحد الخيارات المذكورة هنا لكي تعمل signInWithRedirect() على النحو المنشود في بيئات الإنتاج في جميع المتصفّحات.
نظرة عامة
لإجراء
مسار signInWithRedirect()
لك وللمستخدمين، فإن حزمة SDK لـ Firebase لمصادقة Firebase تستخدم
إطار iframe من مصادر متعددة يرتبط بنطاق استضافة Firebase لتطبيقك.
إلا أنّ هذه الآلية لا تعمل مع المتصفّحات التي تحظر جهات خارجية.
إمكانية الوصول إلى مساحة التخزين.
وبما أنّ توجيه المستخدمين إلى إيقاف ميزات تقسيم مساحة التخزين على المتصفّح نادرًا ما يكون متاحًا، عليك بدلاً من ذلك تطبيق أحد خيارات الإعداد التالية على تطبيقك، حسب تفاصيل حالة الاستخدام التي تستخدمها.
إذا كنت تستضيف تطبيقك باستخدام "استضافة Firebase" على نطاق فرعي من firebaseapp.com، لن تتأثر بهذه المشكلة وليس عليك اتّخاذ أي إجراء.
إذا كنت تستضيف تطبيقك باستخدام استضافة Firebase على نطاق خاص أو نطاق فرعي من web.app، استخدِم
الخيار 1.
الخيار 1: تعديل إعدادات Firebase لاستخدام نطاقك الخاص باعتباره authDomain
إذا كنت تستضيف تطبيقك من خلال استضافة Firebase باستخدام نطاق خاص، يمكنك:
يجب إعداد حزمة تطوير البرامج (SDK) لمنصّة Firebase لاستخدام نطاقك الخاص باسم authDomain. هذا النمط
أن التطبيق وإطار iframe للمصادقة يستخدمان النطاق نفسه، ما يمنع
مشكلة تسجيل الدخول. (إذا لم تكن تستخدم استضافة Firebase، ستحتاج إلى استخدام
خيار مختلف). تأكد من إعداد النطاق الخاص على نفس
المشروع الذي تستخدمه للمصادقة.
لتعديل تهيئة Firebase لاستخدام نطاقك الخاص كنطاق مصادقة، اتّبِع الخطوات التالية:
ما يلي:
اضبط حزمة تطوير برامج JavaScript JS من Firebase لاستخدام نطاقك الخاص باسم authDomain:
إضافة authDomain الجديد إلى قائمة النطاقات المعتمَدة لدى موفِّر OAuth
معرّفات الموارد المنتظمة (URI) لإعادة التوجيه. وتعتمد كيفية تنفيذ ذلك على موفر الخدمة، ولكن بشكل عام
يمكنك اتباع "قبل البدء" في أي مزود خدمة
التعليمات (على سبيل المثال،
Facebook). تم تحديث معرف الموارد المنتظم (URI) إلى
يبدو تفويض
https://<the-domain-that-serves-your-app>/__/auth/handler — يلي
/__/auth/handler مهمة.
وبالمثل، في حال استخدام موفّر SAML، يمكنك إضافة authDomain الجديد إلى
عنوان URL لخدمة مستهلكي تأكيد بيانات SAML (ACS).
يمكنك إعادة النشر باستخدام "استضافة Firebase" إذا لزم الأمر لاسترجاع أحدث ملف إعداد Firebase تتم استضافته على /__/firebase/init.json.
الخيار 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" تطبيق مساعد تسجيل الدخول.
رمز يعيد التوجيه إلى موفّر الهوية، وعند نجاحه، يعيد التوجيه مرة أخرى
إلى نطاق التطبيق
وعند عودة مسار المصادقة إلى نطاق تطبيقك، فإن مساحة تخزين المتصفح
الوصول إلى نطاق مساعد تسجيل الدخول يُعد هذا الخيار
ويؤدي اتباع واحد (للاستضافة الذاتية للرمز) إلى إلغاء إمكانية الوصول إلى مساحة التخزين متعددة المصادر، والتي يتم حظرها بواسطة المتصفحات.
عليك إعداد خادم وكيل عكسي على خادم تطبيقك حتى يتم تنفيذ طلبات 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. ومع ذلك، لا ينجح هذا الأسلوب مع شركة Apple
أو SAML. لا يمكنك استخدام هذا الخيار إلا في حال إعداد الخادم الوكيل العكسي في
الخيار 3 غير ممكن.
تتضمّن عملية استضافة الرمز المساعِد الخطوات التالية:
تنزيل الملفات المطلوب استضافتها من موقع <project>.firebaseapp.com حسب
في تنفيذ الأوامر التالية:
استضِف الملفات المذكورة أعلاه ضمن نطاق تطبيقك. يُرجى التأكد من أنّ خادم الويب
يمكن الرد على https://<app domain>/__/auth/<filename>https://<app domain>/__/firebase/init.json
في ما يلي نموذج لتنفيذ خادم يعمل على تنزيل الملفات ويستضيفها.
ننصح بتنزيل الملفات ومزامنتها بشكل دوري لضمان الحصول على أحدث إصلاحات الأخطاء والميزات.
اتّبِع الخطوات الواردة في
الخيار 1
لتحديث redirect_uri المصرّح به وauthDomain. بعد إعادة النشر
لتطبيقك، من المفترض ألا يتم الوصول إلى مساحة التخزين من مصادر متعددة.
الخيار 5: التعامل مع عملية تسجيل دخول مقدِّم الخدمة بشكل مستقل
توفر حزمة SDK لمصادقة Firebase
signInWithPopup() و
signInWithRedirect() باسم
والملاءمة للالتفاف حول المنطق المعقد وتجنب الحاجة إلى
حزمة SDK أخرى. يمكنك تجنب استخدام أي من الطريقتين تمامًا من خلال التوقيع بشكل مستقل
إلى مزود الخدمة، ثم استخدام
signInWithCredential() إلى
تبادل بيانات اعتماد الموفر للحصول على بيانات اعتماد مصادقة Firebase.
على سبيل المثال، يمكنك استخدام دالة الرسم
حزمة تطوير البرامج (SDK) الخاصة بتسجيل الدخول بحساب Googleرمز نموذجي
للحصول على بيانات اعتماد حساب 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)."]]
