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

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

סקירה כללית

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

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

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

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

  2. חשוב לוודא ש-continue_uri נמצא ברשימת הדומיינים המורשים.

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

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

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

WebWeb
  // 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. צריך להגדיר שרת 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 היא לא מעשית.

אירוח קוד ה-Assistant כולל את השלבים הבאים:

  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, באמצעות הרצת הקוד הבא:

WebWeb
  // `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 הן כאן.