ניהול סשנים של רכישות מתוך האפליקציה

בדף הזה מוסבר איך Identity-Aware Proxy ‏(IAP) מטפל בבקשה עם סשן שפג תוקפו, ואיך לוודא שבקשות של אפליקציית AJAX ובקשות WebSocket יצליחו.

תהליך הסשן של IAP

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

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

• המשתמש יצא מהחשבון שלו

• החשבון שלהם הושעה

• החשבון דורש איפוס סיסמה

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

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

תפוגת תוקף של סשן IAP

בתהליך התחברות באמצעות חשבון Google, הסשן של IAP מקושר לסשן ההתחברות הבסיסי של Google, והוא מסתיים רק כשהסשן הזה מסתיים, בלי קשר לטענת הנכוֹנוּת (claim) של exp ב-JWT שנשלח בכותרת ההרשאה.

באימות פרוגרמטי, IAP מכבד את ההצהרה exp ב-JWT שנשלח בכותרת Authorization.

בתהליך ההתחברות ל-Identity Platform, הסשן ב-IAP נשאר בתוקף עד שעה אחרי שהמשתמש מתנתק.

הודעת כניסה לחשבונות Google

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

בקשות WebSocket

‫IAP תומך ב-WebSocket רק לבקשות ראשוניות, ולא בודק את ההרשאה באופן רציף. כשמתקבלת בקשת WebSocket, היא מתחילה בבקשת HTTP Upgrade. ‫IAP מעריך את הבקשה כבקשת HTTP GET רגילה. אחרי שהבקשה מאושרת, IAP מעביר את הבקשה לשרת ופותח חיבור קבוע. לאחר מכן, IAP לא עוקב אחרי הבקשות ולא מרענן את הסשן.

תגובות לסשנים שפג תוקפם

‫IAP מחזיר תגובות שונות לסשנים שפג תוקפם, בהתאם לסוג הבקשה.

בקשות שאינן מסוג AJAX

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

בקשות AJAX

ב-Chrome ובדפדפנים אחרים מפסיקים בהדרגה את השימוש בקובצי Cookie של צד שלישי. ההמלצות לשליחת בקשות AJAX בדף הזה לא יעבדו אם קובצי Cookie של צד שלישי מושבתים. עם זאת, ההמלצות שניתנו ימשיכו לפעול אם גם המקור וגם היעד של בקשות ה-AJAX הם מאותו אתר.

לקבלת הוראות לניהול קובצי Cookie של צד שלישי ב-Chrome, ראו איך מוחקים, מאשרים ומנהלים קובצי Cookie ב-Chrome

‫IAP מסתמך על קובצי Cookie כדי לנהל סשנים של משתמשים. הוא גם מסתמך על רצף של הפניות אוטומטיות כדי ליצור סשן כחלק מתהליך ההתחברות. לא תמיד אפשר ליצור סשן אם האפליקציה משתמשת בשיתוף משאבים ממקורות שונים (CORS) כדי לשלוח בקשות AJAX לאפליקציה שמוגנת באמצעות IAP.

כדי לשלוח בקשת CORS לאפליקציה שמוגנת באמצעות IAP, צריך ליצור סשן IAP מחוץ לפס. שימו לב: בבקשת AJAX ששולחת בקשת CORS מ-source_domain->target_domain, כאשר target_domain מארח את האפליקציה שמוגנת באמצעות IAP, צריך ליצור סשן ב-target_domain. אין דרך לשתף קובצי Cookie בין source_domain לבין target_domain.

אחרי שהסשן ב-target_domain נוצר, המפתח צריך לאפשר שליחה של פרטי כניסה בבקשה. כברירת מחדל, שיטות JavaScript לא מצרפות קובצי Cookie לבקשות. כדי להפעיל את פרטי הכניסה בבקשה, בבקשות שנשלחות עם אובייקט XMLHttpRequest צריך להגדיר את המאפיין withCredentials כ-true, ובבקשות שנשלחות עם Fetch API צריך להגדיר את האפשרות credentials כ-include או כ-same-origin.

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

הסבר על התגובה של IAP

בבקשות AJAX, ‏IAP מחזיר קוד סטטוס HTTP 401: Unauthorized. חשוב לדעת שאי אפשר לזהות בקשות AJAX בצורה מושלמת. אם אתם מקבלים קוד סטטוס 302 בתגובה במקום קוד סטטוס 401 לבקשות AJAX, אפשר להוסיף לבקשות AJAX כותרת X-Requested-With עם הערך "XMLHttpRequest". כך IAP יודע שהבקשה מגיעה מ-JavaScript.

טיפול בתגובת AJAX מסוג HTTP 401

כדי ליצור סשן IAP אחרי שהאפליקציה מקבלת את קוד הסטטוס HTTP 401, האפליקציה יכולה לפתוח חלון חדש לכתובת ה-URL‏ target_domain + ?gcp-iap-mode=DO_SESSION_REFRESH. זהו handler מיוחד שרק יוצר את הסשן של IAP ב-target_domain. אם החלון נשאר פתוח, הסשן ימשיך להתעדכן מדי פעם, והמשתמש יתבקש להזין קלט לפי הצורך. המשתמש יכול לבחור לסגור את החלון, וה-handler של סטטוס HTTP 401 בקוד של המפתח אמור להקפיץ שוב חלון לרענון הסשן לפי הצורך.

שלב 1: משנים את קוד האפליקציה

בדוגמה הבאה אפשר לראות איך לשנות את קוד האפליקציה כדי לטפל בקוד הסטטוס 401 של HTTP ולספק למשתמש קישור לרענון הסשן:

if (response.status === 401) {
  statusElm.innerHTML = 'Login stale. <input type="button" value="Refresh" onclick="sessionRefreshClicked();"/>';
}

שלב 2: מתקינים גורם מטפל מסוג onclick

הקוד לדוגמה הבא מתקין handler של onclick שסוגר את החלון אחרי שהסשן מתרענן:

var iapSessionRefreshWindow = null;

function sessionRefreshClicked() {
  if (iapSessionRefreshWindow == null) {
    iapSessionRefreshWindow = window.open("/?gcp-iap-mode=DO_SESSION_REFRESH");
    window.setTimeout(checkSessionRefresh, 500);
  }
  return false;
}

function checkSessionRefresh() {
  if (iapSessionRefreshWindow != null && !iapSessionRefreshWindow.closed) {
    // Attempting to start a new session.
    // XMLHttpRequests is used by the server to identify AJAX requests
    fetch('/favicon.ico', {
          method: "GET",
          credentials: 'include',
          headers: {
              'X-Requested-With': 'XMLHttpRequest'
          }
    .then((response) => {
      // Checking if browser has a session for the requested app
      if (response.status === 401) {
        // No new session detected. Try to get a session again
        window.setTimeout(checkSessionRefresh, 500);
      } else {
        // Session retrieved.
        iapSessionRefreshWindow.close();
        iapSessionRefreshWindow = null;
      }
    })
    });
  } else {
    iapSessionRefreshWindow = null;
  }
}