أفضل الممارسات لاستخدام SignInWithRedirect على المتصفحات التي تمنع الوصول إلى مساحة التخزين الخارجية

يصف هذا المستند أفضل الممارسات لاستخدام عمليات تسجيل الدخول بإعادة التوجيه على المتصفحات التي تحظر ملفات تعريف الارتباط التابعة لجهات خارجية. يجب عليك اتباع أحد الخيارات المدرجة هنا حتى يعمل signInWithRedirect() على النحو المنشود في بيئات الإنتاج، عبر جميع المتصفحات.

ملخص

لجعل تدفق signInWithRedirect() سلسًا لك وللمستخدمين، تستخدم حزمة JavaScript SDK لمصادقة Firebase إطار iframe مشترك الأصل يتصل بنطاق Firebase Hosting الخاص بتطبيقك. ومع ذلك، لا تعمل هذه الآلية مع المتصفحات التي تمنع الوصول إلى مساحة التخزين الخارجية.

نظرًا لأن مطالبة المستخدمين بتعطيل ميزات تقسيم التخزين على المتصفح نادرًا ما يكون خيارًا، فيجب عليك بدلاً من ذلك تطبيق أحد خيارات الإعداد التالية على تطبيقك، اعتمادًا على تفاصيل حالة الاستخدام الخاصة بك.

• إذا كنت تستضيف تطبيقك باستخدام استضافة Firebase على نطاق فرعي من firebaseapp.com ، فلن تتأثر بهذه المشكلة ولا يلزم اتخاذ أي إجراء.
• إذا كنت تستضيف تطبيقك باستخدام استضافة Firebase على نطاق مخصص أو نطاق فرعي من web.app ، فاستخدم الخيار 1 .
• إذا كنت تستضيف تطبيقك مع خدمة أخرى غير Firebase، فاستخدم الخيار 2 أو الخيار 3 أو الخيار 4 أو الخيار 5 .

الخيار 1: قم بتحديث تكوين Firebase الخاص بك لاستخدام المجال المخصص الخاص بك باعتباره authDomain

إذا كنت تستضيف تطبيقك باستخدام استضافة Firebase باستخدام مجال مخصص، فيمكنك تكوين Firebase SDK لاستخدام مجالك المخصص باعتباره authDomain . وهذا يضمن أن تطبيقك وإطار iframe الخاص بالمصادقة يستخدمان نفس النطاق، مما يمنع مشكلة تسجيل الدخول. (إذا كنت لا تستخدم استضافة Firebase، فستحتاج إلى استخدام خيار مختلف.)

لتحديث تكوين Firebase الخاص بك لاستخدام مجالك المخصص كمجال مصادقة، قم بما يلي:

1. قم بتكوين Firebase JS SDK لاستخدام المجال المخصص الخاص بك باعتباره authDomain :

   const firebaseConfig = {
     apiKey: "<api-key>",
     authDomain: "<the-domain-that-serves-your-app>",
     databaseURL: "<database-url>",
     projectId: "<project-id>",
     appId: "<app-id>"
   };
   

2. أضف authDomain الجديد إلى قائمة موفر OAuth الخاص بمعرفات URI المعتمدة لإعادة التوجيه. ستعتمد كيفية القيام بذلك على الموفر، ولكن بشكل عام يمكنك اتباع قسم "قبل البدء" في أي موفر للحصول على الإرشادات الدقيقة (على سبيل المثال، موفر Facebook ). يبدو عنوان URI المحدث للتفويض كما يلي https://<the-domain-that-serves-your-app>/__/auth/handler — يعد /__/auth/handler اللاحق مهمًا.

   وبالمثل، إذا كنت تستخدم موفر SAML، فأضف authDomain الجديد إلى عنوان URL لخدمة المستهلك لتأكيد SAML (ACS).

الخيار 2: التبديل إلى SignInWithPopup()

استخدم signInWithPopup() بدلاً من signInWithRedirect() . تظل بقية التعليمات البرمجية لتطبيقك كما هي، ولكن يتم استرداد كائن UserCredential بشكل مختلف.

  // Before
  // ==============
  signInWithRedirect(auth, new GoogleAuthProvider());
  // After the page redirects back
  const userCred = await getRedirectResult(auth);

  // After
  // ==============
  const userCred = await signInWithPopup(auth, new GoogleAuthProvider());

  // 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());
```

لا يعد تسجيل الدخول عبر النوافذ المنبثقة مثاليًا دائمًا للمستخدمين، حيث يتم أحيانًا حظر النوافذ المنبثقة بواسطة الجهاز أو النظام الأساسي، ويكون التدفق أقل سلاسة لمستخدمي الأجهزة المحمولة. إذا كان استخدام النوافذ المنبثقة يمثل مشكلة لتطبيقك، فستحتاج إلى اتباع أحد الخيارات الأخرى.

الخيار 3: طلبات مصادقة الوكيل إلى firebaseapp.com

يبدأ تدفق signInWithRedirect بإعادة التوجيه من مجال التطبيق الخاص بك إلى المجال المحدد في معلمة authDomain في تكوين firebase (" .firebaseapp.com" بشكل افتراضي). يستضيف authDomain رمز مساعد تسجيل الدخول الذي يعيد التوجيه إلى موفر الهوية، والذي، عند النجاح، يعيد التوجيه مرة أخرى إلى مجال التطبيق.

عندما يعود تدفق المصادقة إلى مجال التطبيق الخاص بك، يتم الوصول إلى مساحة تخزين المتصفح الخاصة بالمجال المساعد لتسجيل الدخول. يؤدي هذا الخيار والخيار التالي (لاستضافة الكود ذاتيًا) إلى إلغاء الوصول إلى التخزين عبر الأصل، والذي يتم حظره بواسطة المتصفحات.

1. قم بإعداد وكيل عكسي على خادم التطبيق الخاص بك بحيث تتم إعادة توجيه طلبات 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_pass https://<project>.firebaseapp.com;
   }
   

2. اتبع الخطوات الواردة في الخيار 1 لتحديث redirect_uri المعتمد وعنوان URL لـ ACS و authDomain الخاص بك. بمجرد إعادة نشر تطبيقك، لن يحدث الوصول إلى التخزين عبر الأصل مرة أخرى.

الخيار 4: الاستضافة الذاتية لرمز مساعد تسجيل الدخول في نطاقك

هناك طريقة أخرى للتخلص من الوصول إلى التخزين عبر الأصل وهي الاستضافة الذاتية لرمز مساعد تسجيل الدخول إلى Firebase. ومع ذلك، لا يعمل هذا الأسلوب مع تسجيل الدخول عبر Apple أو SAML. استخدم هذا الخيار فقط إذا كان إعداد الوكيل العكسي في الخيار 3 غير ممكن.

تتضمن استضافة الكود المساعد الخطوات التالية:

1. قم بتنزيل الملفات لاستضافتها من موقع <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
   

2. قم باستضافة الملفات المذكورة أعلاه ضمن نطاق التطبيق الخاص بك. تأكد من أن خادم الويب الخاص بك يمكنه الاستجابة لـ https://<app domain>/__/auth/<filename> .

   فيما يلي نموذج لتطبيق الخادم الذي يقوم بتنزيل الملفات واستضافتها. نوصي بتنزيل الملفات ومزامنتها بشكل دوري لضمان الحصول على أحدث إصلاحات الأخطاء والميزات.

3. اتبع الخطوات الواردة في الخيار 1 لتحديث redirect_uri المعتمد و authDomain الخاص بك. بمجرد إعادة نشر تطبيقك، لن يحدث الوصول إلى التخزين عبر الأصل مرة أخرى.

الخيار 5: التعامل مع تسجيل دخول الموفر بشكل مستقل

يوفر Firebase Authentication SDK signInWithPopup() و signInWithRedirect() كطرق ملائمة لتغليف المنطق المعقد وتجنب الحاجة إلى إشراك SDK آخر. يمكنك تجنب استخدام أي من الطريقتين تمامًا عن طريق تسجيل الدخول بشكل مستقل إلى موفر الخدمة الخاص بك، ثم استخدام signInWithCredential() لتبادل بيانات اعتماد الموفر ببيانات اعتماد Firebase Authentication. على سبيل المثال، يمكنك استخدام Google Sign In SDK ، نموذج التعليمات البرمجية للحصول على بيانات اعتماد حساب Google، ثم إنشاء مثيل لبيانات اعتماد Google جديدة، عن طريق تشغيل التعليمات البرمجية التالية:

  // `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);

  // `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.