שיטות מומלצות לשימוש ב-SignInWithRedirect בדפדפנים שחוסמים גישה לאחסון של צד שלישי

במסמך הזה מתוארות שיטות מומלצות לשימוש בכניסות באמצעות הפניה אוטומטית בדפדפנים שחוסמים קובצי cookie של צד שלישי. כדי ש-signInWithRedirect() יפעל כמצופה בסביבות ייצור בכל הדפדפנים, צריך לפעול לפי אחת מהאפשרויות שמפורטות כאן.

סקירה כללית

כדי להפוך את תהליך של signInWithRedirect() שה-SDK של JavaScript עבור אימות ב-Firebase משתמש בצורה חלקה לכם ולמשתמשים iframe ממקורות שונים שמתחבר לדומיין האירוח של האפליקציה ב-Firebase. עם זאת, המנגנון הזה לא פועל בדפדפנים שחוסמים גישה לאחסון של צד שלישי.

בדרך כלל לא ניתן לבקש מהמשתמשים להשבית את התכונות של חלוקת האחסון בדפדפן, לכן מומלץ להחיל באפליקציה אחת מהאפשרויות הבאות להגדרה, בהתאם לפרטים הספציפיים של תרחיש השימוש.

  • אם האפליקציה מתארחת באירוח Firebase בתת-דומיין של firebaseapp.com, הבעיה הזו לא משפיעה עליך ולא נדרשת כל פעולה מצידך.
  • אם אתם מארחים את האפליקציה באמצעות אירוח ב-Firebase בדומיין מותאם אישית או בתת-דומיין של web.app, השתמשו באפשרות 1.
  • אם אתם מארחים את האפליקציה בשירות שאינו Firebase, צריך להשתמש ב- אפשרות 2, אפשרות 3, אפשרות 4, או אפשרות 5.

אפשרות 1: מעדכנים את הגדרות Firebase כך שהדומיין המותאם אישית ישמש כ-authDomain

אם אתם מארחים את האפליקציה באמצעות Firebase Hosting באמצעות דומיין מותאם אישית, תוכלו להגדיר את 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>"
};

  1. מוסיפים את authDomain החדש לרשימת מזהי ה-URI המורשים להפניה אוטומטית (URI) של ספק ה-OAuth. הדרך לעשות את זה תלויה בספק, אבל באופן כללי אפשר לעקוב אחר ההוראות בקטע "לפני שמתחילים" בקטע של כל ספק, מפורטות יותר (לדוגמה, ספק Facebook). ה-URI המעודכן לצורך הרשאה נראה כך: https://<the-domain-that-serves-your-app>/__/auth/handler – ה-/__/auth/handler בסוף חשוב.

    באופן דומה, אם אתם משתמשים בספק SAML, צריך להוסיף את authDomain החדש לכתובת ה-URL של Assertion Consumer Service‏ (ACS) של SAML.

  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: בקשות של אימות שרת proxy ל-firebaseapp.com

התהליך של signInWithRedirect מתחיל בהפניה אוטומטית מדומיין האפליקציה לדומיין שצוין בפרמטר authDomain בתצורה של Firebase (‎.firebaseapp.com כברירת מחדל). authDomain מארח את קוד העזרה לכניסה שמעביר אוטומטית לדף הפנייה של ספק הזהויות, שמעביר אוטומטית בחזרה לדומיין של האפליקציה אם התהליך מסתיים בהצלחה.

כשתהליך האימות חוזר לדומיין של האפליקציה, מתבצעת גישה לאחסון בדפדפן של הדומיין שעוזר בכניסה. האפשרות הזו שימוש בקוד (כדי לארח את הקוד בעצמו) מבטל את הגישה לאחסון ממקורות שונים, שאחרת היא חסומה על ידי דפדפנים.

  1. צריך להגדיר שרת proxy הפוך בשרת האפליקציות כך שיבקשו GET/POST אל https://<app domain>/__/auth/ הועברו אל https://<project>.firebaseapp.com/__/auth/. לוודא שההעברה הזו שקופה לדפדפן. לא ניתן לעשות זאת דרך הפניה אוטומטית מסוג 302.

    אם אתם משתמשים ב-nginx כדי להציג את הדומיין המותאם אישית, הגדרת שרת ה-proxy ההפוך תיראה כך:

    # 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. יש להשתמש באפשרות הזו רק אם ההגדרה של שרת proxy הפוך אפשרות 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: טיפול בכניסה של הספק באופן עצמאי

Firebase Authentication SDK מספק את השיטות 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.