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

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

ملخص

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

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

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

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

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

لتحديث تهيئة 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 لمعرفات الموارد المنتظمة (URIs) المصرح بها لإعادة التوجيه. ستعتمد كيفية القيام بذلك على الموفر ، ولكن بشكل عام يمكنك اتباع قسم "قبل أن تبدأ" في أي مزود للحصول على إرشادات دقيقة (على سبيل المثال ، موفر Facebook ). يبدو عنوان URI المحدث للمصادقة مثل https://<the-domain-that-serves-your-app>/__/auth/handler - اللاحقة /__/auth/handler مهمة.

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

الخيار 2: التبديل إلى تسجيل الدخول مع المنبثقة ()

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

Web version 9

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

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

Web version 8

  // 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: التعامل مع تسجيل دخول الموفر بشكل مستقل

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

Web version 9

  // `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 version 8

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