במאמר הזה מוסבר איך לנהל סשנים באמצעות Identity-Aware Proxy (IAP) אם אתם משתמשים בזהויות חיצוניות לאימות.
רענון הסשנים
הסשנים ב-Identity Platform תקפים למשך שעה אחת. כשפג תוקף של סשן, האפליקציה צריכה להפנות לדף האימות. דף האימות מכיל את אסימון הרענון של Identity Platform. כל עוד פרטי הכניסה של המשתמש תקפים, אפשר להשתמש בהם לאימות מחדש בלי להציג ממשק משתמש כלשהו.
אם המשתמש שינה לאחרונה את כתובת האימייל או הסיסמה שלו, או אם התרחשה פעולה אחרת שגרמה לביטול האסימון שלו, הוא יצטרך להשלים שוב את תהליך האימות.
טיפול בבקשות שאינן AJAX
בקשות שאינן AJAX מטופלות באופן אוטומטי באמצעות הפניה אוטומטית של האפליקציה, בהנחה שדף האימות מוגדר בצורה נכונה.
טיפול בבקשות AJAX
ב-Chrome ובדפדפנים אחרים מפסיקים בהדרגה את השימוש בקובצי Cookie של צד שלישי. ההמלצות לשליחת בקשות AJAX בדף הזה לא יפעלו אם קובצי Cookie של צד שלישי מושבתים. עם זאת, ההמלצות שסופקו ימשיכו לפעול אם המקור והיעד של הבקשות מסוג AJAX הם מאותו אתר.
הוראות לניהול קובצי Cookie של צד שלישי ב-Chrome מופיעות במאמר איך מוחקים, מאשרים ומנהלים קובצי Cookie ב-Chrome.
אם שולחים בקשת AJAX עם טוקן שתוקפו פג, הבקשה תחזיר קוד סטטוס 401: Unauthorized. כדי לטפל בבעיה הזו, אפשר להטמיע אחד מהפתרונות הבאים:
- צריך לשנות את קוד האפליקציה כדי לטפל בקודי סטטוס של HTTP
401. - מוסיפים
iframeלאפליקציה כדי להפנות לרענון הסשן. - מנחים את המשתמשים לטעון מחדש את הסשן באופן ידני בכרטיסייה נפרדת.
אם אתם מקבלים קוד סטטוס 302 במקום 401 בתגובה לבקשות AJAX, צריך להוסיף כותרת X-Requested-With עם הערך XMLHttpRequest.
המידע הזה מאפשר ל-IAP לדעת שהבקשה מגיעה מ-JavaScript.
טיפול בשגיאת HTTP 401 באופן פרוגרמטי
הדרך המומלצת לרענן סשן AJAX היא באמצעות טיפול פרוגרמטי בקודי סטטוס של HTTP 401. לשם כך:
מעדכנים את קוד האפליקציה כדי לטפל בשגיאה.
מוסיפים handler שפותח חלון לאימות מחדש של המשתמש, ואז סוגר אותו כשהתהליך מסתיים.
שימוש ב-iframe
אם אין לכם אפשרות לטפל ב-HTTP 401 באופן פרוגרמטי, הפתרון הטוב הבא הוא להוסיף iframe לאפליקציה שמפנה לרענון הסשן.
כדי להשתמש ב-iframe, צריך להגדיר דף כניסה מותאם אישית באותו דומיין של אפליקציית האינטרנט שמוגנת על ידי IAP. אחרת, המשתמשים ייתקלו בשגיאות שקשורות למקורות שונים. מידע נוסף על הגדרת דף כניסה זמין במאמר בנושא יצירת דף כניסה בהתאמה אישית.
דוגמה לשימוש ב-iframe:
<iframe src="https://example.com/some/path?gcp-iap-mode=SESSION_REFRESHER" style="width:0;height:0;border:0; border:none;"></iframe>
טעינת רענון הסשן
כמוצא אחרון, אפשר להנחות את המשתמשים לטעון מחדש את רענון הסשן באופן ידני. מוסיפים לאפליקציה או לתיעוד שלה הנחיות למשתמשים לפתוח את כתובת ה-URL הבאה בכרטיסייה נפרדת:
https://example.com/some/path?gcp-iap-mode=SESSION_REFRESHER
הוצאת משתמשים מהחשבון
כדי להוציא משתמש ממשאב IAP, משתמשים בפרמטר השאילתה ?gcp-iap-mode=GCIP_SIGNOUT. לדוגמה, באפליקציית App Engine, כתובת ה-URL נראית כך:
https://example.com/some/path?gcp-iap-mode=GCIP_SIGNOUT
אחרי שהמשתמשים יתנתקו מהחשבון, הם יופנו חזרה לדף הכניסה.
כדי להוציא משתמש מכל המשאבים והסשנים, צריך להפנות אותו לכתובת URL לאימות עם מפתח ה-API והפרמטר mode=signout שנוספו כפרמטרים. לדוגמה:
https://auth.example.com/?apiKey=API-KEY&mode=signout
המשתמשים יישארו בדף אחרי שהיציאה מהחשבון תושלם. מומלץ להטמיע את פונקציית הקריאה החוזרת completeSignOut() באובייקט AuthenticationHandler כדי לספק למשתמש משוב על כך שהוא התנתק בהצלחה.
מעבר בין דיירים
במקרים מסוימים, משתמש עשוי לרצות לבצע אימות בכמה דיירים עבור אותו משאב IAP. לדוגמה, יכול להיות שהם שייכים לכמה דיירים שמעניקים רמות גישה שונות, והם רוצים לעבור לדייר עם פחות או יותר הרשאות.
כדי לאלץ את תהליך בחירת הדייר להתחיל מחדש, משתמשים ב-?gcp-iap-mode=CLEAR_LOGIN_COOKIE. לדוגמה, באפליקציית App Engine, כתובת ה-URL יכולה להיראות כך:
https://PROJECT-ID.appspot.com/some/path?gcp-iap-mode=CLEAR_LOGIN_COOKIE