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

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

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

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

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

• המשתמש יצא מהחשבון שלו
• החשבון שלהם הושעה
• נדרש איפוס סיסמה בחשבון

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

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

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

בתהליך כניסה באמצעות חשבון Google, סשן ה-IAP קשור לסשן הכניסה הבסיסי לחשבון Google, והתוקף שלו פג רק כשתוקף הסשן הזה פג, ללא קשר להצהרה exp ב-JWT שנשלח בכותרת ההרשאה.

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

בתהליך הכניסה של 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 מ-target_domainsource_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;
  }
}