أفضل الممارسات لاستخدام ميزةsignInWithRedirect في المتصفّحات التي تحظر إمكانية الوصول إلى مساحة تخزين الجهات الخارجية

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

نظرة عامة

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

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

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

الخيار 1: تعديل إعدادات Firebase لاستخدام نطاقك الخاص باعتباره authDomain

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

لتعديل تهيئة Firebase لاستخدام نطاقك الخاص كنطاق مصادقة، اتّبِع الخطوات التالية: ما يلي:

  1. اضبط حزمة تطوير برامج JavaScript JS من Firebase لاستخدام نطاقك الخاص باسم authDomain:

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

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

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

  2. تأكَّد من أنّ continue_uri في قائمة النطاقات المعتمَدة.

  3. يمكنك إعادة النشر باستخدام "استضافة Firebase" إذا لزم الأمر لاسترجاع أحدث ملف إعداد Firebase تتم استضافته على /__/firebase/init.json.

الخيار 2: الانتقال إلى SignInWithPopup()

استخدام signInWithPopup() بدلاً من signInWithRedirect() تشير رسالة الأشكال البيانية يظل باقي رمز تطبيقك كما هو، إلا أن كائن 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());
```

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

الخيار 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
wget https://<project>.firebaseapp.com/__/firebase/init.json

  2. استضِف الملفات المذكورة أعلاه ضمن نطاق تطبيقك. يُرجى التأكد من أنّ خادم الويب يمكن الرد على https://<app domain>/__/auth/<filename> https://<app domain>/__/firebase/init.json

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

  3. اتّبِع الخطوات الواردة في الخيار 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();
  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 هي هنا.