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

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

הערה: החל מ-24 ביוני 2024, כדי שכניסה באמצעות הפניה אוטומטית תפעל ב-Google Chrome M115 ואילך, צריך להטמיע את אחת מהאפשרויות. זה כבר נדרש ב-Firefox 109 ואילך וב-Safari 16.1 ואילך.

סקירה כללית

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

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

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

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

1. מוסיפים את ה-authDomain החדש לרשימת כתובות ה-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 מאוחזר באופן שונה.

גרסה 9 לאינטרנט

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

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

גרסה 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: בקשות אימות של שרת 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/__/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. כדי לעדכן את redirect_uri המורשה ואת authDomain, פועלים לפי השלבים באפשרות 1. אחרי שתפרסו מחדש את האפליקציה, הגישה לאחסון ממקורות שונים לא אמורה להתרחש יותר.

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

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

חשוב: זו גישה מורכבת שמשתמשת בערכות SDK נוספות, ויכול להיות שהיא תהיה מאוד מורכבת לספקי SAML.

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

גרסה 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);

גרסה 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(), שאר הפונקציות של האפליקציה פועלות כמו קודם.

כאן מוסבר איך מקבלים פרטי כניסה של אפל.