גישה דרך פורטל APM: למי שייך מושב האפליקציה?
חמש בדיקות להחלטת פרסום עם BIG-IP Portal Access: היקף המשאב, מושב ה-backend, שני טיימרים, משמעות היציאה ומגבלות השכתוב.
פרסום אפליקציית אינטראנט דרך BIG-IP APM Portal Access הוא החלטה על מושבים, לא על העתקת שרת וירטואלי. הפורטל מכניס את המשתמש, פרופיל השכתוב מחזיק בקשות נבחרות בנתיב השער, והאפליקציה עדיין מחזיקה במושב משלה. חמש בדיקות מפרידות בין עיצוב שמתנהג באופן צפוי לבין עיצוב שבו מחלקת התמיכה לומדת על פסקי זמן משתמש אחר משתמש. עברו עליהן לפי הסדר ועצרו בראשונה שאינה נכונה.
בדיקה 1: המשאב מפורסם, לא רק מקושר
סימנייה ב-webtop מוכיחה שמשתמש רואה רשומה. היא אינה מוכיחה שהאפליקציה מפורסמת. חפשו את פרופיל הגישה, פרופיל השכתוב והשרת הווירטואלי שמשלב ביניהם, ואז ודאו שהקצאת המשאב מצביעה על האפליקציה שאתם חושבים. אם אחד מהשלושה חסר או אינו עקבי, שאר הרשימה חסר משמעות.
המקרה של פרסום חלקי נראה תקין בנקודת הכניסה. השרת הווירטואלי נושא את פרופיל הגישה בעוד פרופיל השכתוב מוגבל ל-URI של משאב אחר, כך שהרשומה ב-webtop מופיעה והעמוד הראשון נטען, ואז בקשות נתיב המשנה עוזבות את נתיב השער ומגיעות ל-backend ישירות. התמונה ההפוכה היא משאב שהוקצה לאפליקציה הלא נכונה: הסימנייה נפתחת, והיא פותחת משהו שאיש לא אישר.
בדיקה 2: מושב ה-backend הוא מצב נפרד
ה-backend יכול לדרוש אימות משלו גם כשה-APM מחשיב את המשתמש כמחובר. שילוב SSO נתמך קובע את היחס הזה עבורכם, אבל קבלת הכניסה לפורטל אינה גורמת לכל אפליקציה לקבל את אותם פרטי גישה או את אותו קוקי מושב. אם SSO אינו מוגדר למשאב, האפליקציה תבקש כניסה משלה בתוך פורטל שכבר מאומת.
השבתת SSO כדי לשנות את ההנחיה הנראית היא קיצור דרך נפוץ וגרוע: היא משנה את עיצוב האימות בלי לגעת במחזור החיים שיצר את ההנחיה. החליטו במקום זאת אם כניסת ה-backend צריכה להופיע בכלל, ואם כן, עשו אותה לחלק מפורש מהזרימה המפורסמת.
בדיקה 3: יש שני שעונים, והם אינם אותו שעון
פרופיל הגישה של APM נושא פסק זמן חוסר פעילות ותוחלת חיים מרבית של מושב. האפליקציה נושאת טיימר חוסר פעילות משלה ותפוגת קוקי. הארכת הטיימר של הפורטל אינה מאריכה את מושב האפליקציה, וקיצור מושב האפליקציה אינו מנתק את המשתמש מהפורטל.
| Timer | Owner | What it ends |
|---|---|---|
| Inactivity timeout | APM access profile | the portal session after idle time |
| Maximum lifetime | APM access profile | the portal session regardless of activity |
| Application cookie | Backend application | the application session inside a live portal |
הקריאה הקלאסית לתמיכה נובעת מזוג לא תואם: הפורטל עדיין תקף, מושב האפליקציה לא, והמשתמש רואה טופס כניסה שנראה סותר את הפורטל. זו התנהגות נכונה, לא תקלה, והפתרון הוא לבחור איזה שעון צריך לפוג ראשון עבור האפליקציה הזו.
בדיקה 4: ליציאה יש היקף מוגדר
כתבו מה צריך כפתור היציאה של האפליקציה לסיים: רק את האפליקציה הזו, את כל מושב ה-APM, או מושב רחב יותר של ספק הזהות. פרופיל הגישה תומך ברשימת URI ליציאה עם השהיה אופציונלית, וכך אתם גורמים ליציאה מהאפליקציה לסיים את מושב הפורטל כשזה הדרוש. בלי זה, יציאה מהאפליקציה משאירה את הפורטל חי, ובקשה שלאחר מכן עלולה להכניס את המשתמש בחזרה בשקט.
חשבו את ההשפעה על משאבים אחרים באותו פורטל. אם יציאה מאפליקציה אחת מסיימת את המושב של שישה אחרים, משתמשים יקראו לזה באג אלא אם ההתנהגות סוכמה מראש עם בעל האפליקציה. סגירת כרטיסייה וחזרה ל-webtop אינן הוכחה שמשהו הסתיים.
בדיקה 5: האפליקציה שורדת את השכתוב
Portal Access משכתב תוכן ווב נבחר, ולשכתוב יש קצוות. תכונות מודרניות בצד הלקוח, תהליכי רקע, זרימות העלאה וכניסה פדרטיבית עלולים ליפול מחוץ למה שגרסה נתונה מטפלת בו. מטריצת התאימות לפי גרסה של F5 היא המסמך שיש לקרוא לפני התחייבות, כי המגבלות תלויות בגרסה.
בדקו את הזרימות החשובות ולא את עמוד הנחיתה: היכנסו, עברו בכל פונקציה נדרשת, העלו אם האפליקציה מעלה, תנו למושב המיועד לפוג ועקבו אחרי כל נתיב יציאה. עמוד שמתרנדר פעם אחת אינו הוכחה שהאפליקציה עובדת.
כשזרימה נדרשת אינה ניתנת לשכתוב, עברו לעיצוב מתועד של פדרציה, פרוקסי הפוך או גישת רשת. פורטל דפדפן שמתבקש להתנהג כמו מנהרה כללית יעבור את ההדגמה וייכשל בביקורת.