Пристап преку APM портал: чија е сесијата на апликацијата?

Објавувањето на интранет апликација преку BIG-IP APM Portal Access е одлука за сесии, а не за копирање на виртуелен сервер. Порталот го пушта корисникот внатре, профилот за препишување ги задржува избраните барања на патеката на портата, а апликацијата сè уште има сопствена сесија. Пет проверки раздвојуваат дизајн што се однесува предвидливо од оној каде што службата за поддршка дознава за тајмаутите корисник по корисник. Изведете ги по ред и запрете на првата што не е точна.

Проверка 1: ресурсот е објавен, а не само поврзан

Обележувачот во webtop докажува дека корисникот гледа запис. Тој не докажува дека апликацијата е објавена. Побарајте го профилот за пристап, профилот за препишување и виртуелниот сервер што ги поврзува, потоа потврдете дека доделувањето на ресурсот покажува на апликацијата што ја мислите. Ако некој од тие три недостасува или е неконзистентен, остатокот од списокот е бесмислен.

Случајот на половично објавување изгледа здраво на влезната точка. Виртуелниот сервер го носи профилот за пристап, додека профилот за препишување е ограничен на друг URI на ресурс, па записот во webtop се појавува и првата страница се вчитува, потоа барањата на подпатеката ја напуштаат патеката на портата и стигнуваат до backend директно. Огледалната слика е ресурс доделен на погрешна апликација: обележувачот се отвора и отвора нешто што никој не го одобрил.

Проверка 2: сесијата на backend е одделна состојба

Backend може да бара сопствена автентикација дури и кога APM го смета корисникот за најавен. Поддржаната SSO интеграција ја воспоставува таа врска наместо вас, но прифаќањето на најавата на порталот не прави секоја апликација да ги прифати истите акредитиви или истото cookie за сесија. Ако SSO не е конфигуриран за ресурсот, апликацијата ќе побара сопствена најава во веќе автентициран портал.

Исклучувањето на SSO за да се смени видливиот потсетник е чест и лош кратен пат: го менува дизајнот на автентикација без да го допре животниот циклус што го создал потсетникот. Наместо тоа, одлучете дали најавата на backend воопшто треба да се појавува, и ако треба, направете ја експлицитен дел од објавениот тек.

Проверка 3: има два часовници и тие не се истиот часовник

Профилот за пристап на APM носи тајмаут за неактивност и максимален животен век на сесијата. Апликацијата носи сопствен тајмер за мирување и истекот на cookie. Продолжувањето на тајмерот на порталот не ја продолжува сесијата на апликацијата, а скратувањето на сесијата на апликацијата не го одјавува корисникот од порталот.

Класичниот повик за поддршка произлегува од неусогласен пар: порталот е сè уште валиден, сесијата на апликацијата не е, а корисникот гледа формулар за најава што навидум му противречи на порталот. Тоа е правилно однесување, а не дефект, и решението е да се избере кој часовник треба прв да истече за оваа апликација.

Проверка 4: одјавувањето има определен опсег

Запишете што треба да заврши копчето за одјавување на апликацијата: само таа апликација, целата APM сесија или поширока сесија на давателот на идентитет. Профилот за пристап поддржува список на URI за одјавување со опционално одложување, и така одјавувањето на апликацијата ја завршува сесијата на порталот кога тоа е барањето. Без тоа, одјавувањето на апликацијата го остава порталот жив, а следното барање може тивко повторно да го најави корисникот.

Сметајте на ефектот врз другите ресурси во истиот портал. Ако одјавувањето од една апликација ја заврши сесијата на шест други, корисниците ќе го наречат дефект, освен ако однесувањето не било претходно договорено со сопственикот на апликацијата. Затворањето јазиче и враќањето на webtop не се доказ дека нешто завршило.

Проверка 5: апликацијата го преживува препишувањето

Portal Access препишува избрана веб-содржина, а препишувањето има рабови. Современите функции на страната на клиентот, позадинските работници, тековите за прикачување и федеративната најава можат да паднат надвор од она што го обработува дадено издание. матрицата за компатибилност по верзии на F5 е документот што треба да се прочита пред да се обврзете, бидејќи границите зависат од изданието.

Тестирајте ги тековите што се важни, а не почетната страница: најавете се, поминете низ секоја потребна функција, прикачете ако апликацијата прикачува, оставете предвидената сесија да истече и следете ја секоја патека за одјавување. Страница што се прикажува еднаш не е доказ дека апликацијата работи.

Кога потребниот тек не може да се препише, преминете на документиран дизајн за федерација, обратен прокси или мрежен пристап. Браузерски портал од кој се бара да се однесува како општ тунел ќе ја помине демонстрацијата и ќе падне на ревизијата.