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

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

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

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

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

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

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

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

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

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

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

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

הודעה להתחברות לחשבונות Google

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

בקשות WebSocket

‫IAP תומך ב-WebSocket רק לבקשות ראשוניות, ולא בודק הרשאה באופן רציף. כשמתקבלת בקשת WebSocket, היא מתחילה בבקשת HTTP Upgrade. ‫IAP מעריך את זה כבקשת GET HTTP רגילה. אחרי שהבקשה מאושרת, 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

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

טיפול בתגובת AJAX של HTTP 401

כדי ליצור סשן של רכישה באפליקציה אחרי שהאפליקציה מקבלת 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;
  }
}