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

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

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

  3. ודא continue_uri שלך נמצא ברשימת הדומיינים המורשים .

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

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

השתמש signInWithPopup() במקום signInWithRedirect() . שאר הקוד של האפליקציה שלך נשאר זהה, אבל אובייקט UserCredential מאוחזר בצורה שונה.

API מודולרי אינטרנט

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

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

API עם מרחב שמות אינטרנט

  // 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 כדי לשרת את הדומיין המותאם אישית שלך, תצורת ה-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. השתמש באפשרות זו רק אם ההגדרה של פרוקסי הפוך באופציה 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 Authentication. לדוגמה, אתה יכול להשתמש ב- Google Sign In SDK , קוד לדוגמה כדי לקבל אישור חשבון Google, ולאחר מכן ליצור אישור חדש של Google, על ידי הפעלת הקוד הבא:

API מודולרי אינטרנט

  // `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);

API עם מרחב שמות אינטרנט

  // `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() , שאר האפליקציה שלך מתפקדת כמו קודם.

הוראות לקבלת אישור אפל נמצאות כאן .