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

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

סקירה כללית

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

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

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

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

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

2. מוודאים שכתובת ה-URL של continue_uri מופיעה ברשימת הדומיינים המורשים.

3. אם צריך, פורסים מחדש באמצעות Firebase Hosting כדי לאחזר את קובץ התצורה העדכני ביותר של Firebase שמתארח בכתובת /__/firebase/init.json.

אפשרות 2: מעבר אל signInWithPopup()‎

במקום signInWithRedirect(), צריך להשתמש ב-signInWithPopup(). שאר הקוד של האפליקציה נשאר ללא שינוי, אבל אובייקט 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: העברת בקשות אימות של שרת proxy אל firebaseapp.com

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

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

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

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

   # reverse proxy for signin-helpers for popup/redirect sign in.
   location /__/auth {
     proxy_pass https://<project>.firebaseapp.com;
   }
   

2. פועלים לפי השלבים באפשרות 1 כדי לעדכן את redirect_uri, את כתובת אתר של ACS ואת authDomain המורשים. אחרי שתפרסו מחדש את האפליקציה, הגישה לאחסון ממקורות שונים לא אמורה לקרות יותר.

אפשרות 4: אירוח עצמי של קוד הכלי לסיוע בכניסה בדומיין

דרך נוספת למנוע גישה לאחסון ממקורות שונים היא לארח בעצמכם את קוד העזרה לכניסה ל-Firebase. עם זאת, הגישה הזו לא עובדת עם כניסה באמצעות חשבון אפל או עם SAML. משתמשים באפשרות הזו רק אם אי אפשר להשתמש בהגדרת ה-reverse-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/__/auth/links
   wget https://<project>.firebaseapp.com/__/auth/links.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. לדוגמה, אפשר להשתמש ב-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 זמינות כאן.