Достъп през портала на APM: кой притежава сесията на приложението?
Пет проверки за решение за публикуване през BIG-IP Portal Access: обхват на ресурса, сесия на бекенда, два таймера, значение на изход и граници на презаписването.
Публикуването на вътрешно приложение през BIG-IP APM Portal Access е решение за сесиите, а не за копиране на виртуален сървър. Порталът допуска потребителя, профилът за презаписване задържа избрани заявки по пътя на шлюза, а приложението продължава да притежава собствена сесия. Пет проверки разделят дизайн, който се държи предвидимо, от такъв, при който службата за поддръжка научава за таймаутите потребител по потребител. Изпълнете ги по ред и спрете при първата, която не е вярна.
Проверка 1: ресурсът е публикуван, а не само свързан
Отметка в webtop доказва, че потребителят вижда запис. Тя не доказва, че приложението е публикувано. Потърсете профила за достъп, профила за презаписване и виртуалния сървър, който ги обединява, след което потвърдете, че назначението на ресурса сочи към приложението, което мислите. Ако някое от тези три липсва или е несъответстващо, останалата част от списъка е безсмислена.
Случаят на половин публикуване изглежда здрав при входната точка. Виртуалният сървър носи профила за достъп, докато профилът за презаписване е ограничен до друг URI на ресурс, така че записът в webtop се появява и първата страница се зарежда, а после заявките по подпътя напускат пътя на шлюза и достигат бекенда директно. Огледалният случай е ресурс, назначен на грешно приложение: отметката се отваря и отваря нещо, което никой не е одобрил.
Проверка 2: сесията на бекенда е отделно състояние
Бекендът може да изисква собствено удостоверяване, дори когато APM смята потребителя за влязъл. Поддържаната SSO интеграция установява тази връзка вместо вас, но приемането на порталния вход не прави така, че всяко приложение да приема същите идентификационни данни или същата сесийна бисквитка. Ако SSO не е конфигуриран за ресурса, приложението ще поиска собствен вход вътре в уже удостоверения портал.
Изключването на SSO, за да промените видимата подкана, е често срещан и лош пряк път: то променя дизайна на удостоверяването, без да пипа жизнения цикъл, който е създал подканата. Вместо това решете дали входът в бекенда трябва да се появява изобщо, и ако трябва, направете го изрична част от публикувания поток.
Проверка 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 е документът, който трябва да прочетете преди ангажимент, защото границите зависят от изданието.
Тествайте потоците, които имат значение, а не началната страница: влезте, преминете през всяка необходима функция, качете, ако приложението качва, оставете предвидената сесия да изтече и следвайте всеки път на изход. Страница, която се визуализира веднъж, не е доказателство, че приложението работи.
Когато необходим поток не може да бъде презаписан, преминете към документиран дизайн за федериране, обратно прокси или мрежов достъп. Браузърен портал, от който се иска да се държи като общ тунел, ще мине демото и ще се провали на одита.