Qasja në portalin APM: e kujt është sesioni i aplikacionit?

Publikimi i një aplikacioni intranet përmes BIG-IP APM Portal Access është një vendim për sesionet, jo për kopjimin e një serveri virtual. Portali e lejon përdoruesin të hyjë, profili i rishkrimit mban kërkesat e zgjedhura në rrugën e gateway-it, dhe aplikacioni vazhdon të ketë sesionin e vet. Pesë kontrolle ndajnë një dizajn që sillet në mënyrë të parashikueshme nga një tjetër ku ndihma mëson për afatet përdorues pas përdoruesi. Kryejini sipas radhës dhe ndaloni në të parin që nuk është i vërtetë.

Kontrolli 1: burimi është publikuar, jo vetëm i lidhur

Një faqerojtës në webtop provon që përdoruesi sheh një zë. Nuk provon që aplikacioni është publikuar. Kërkoni profilin e qasjes, profilin e rishkrimit dhe serverin virtual që i kombinon, pastaj konfirmoni që caktimi i burimit tregon aplikacionin që mendoni. Nëse mungon ose është jokonsistent ndonjë nga të tre, pjesa tjetër e listës është pa kuptim.

Rasti gjysmë i publikuar duket i shëndetshëm në pikën e hyrjes. Serveri virtual mban profilin e qasjes ndërsa profili i rishkrimit është i kufizuar në një URI tjetër burimi, kështu që zëri në webtop shfaqet dhe faqja e parë ngarkohet, pastaj kërkesat e nënshtegut lënë rrugën e gateway-it dhe arrijnë te backend direkt. Pasqyra e kundërt është një burim i caktuar aplikacionit të gabuar: faqerojtësi hapet, dhe hap diçka që askush nuk e ka miratuar.

Kontrolli 2: sesioni i backend është një gjendje më vete

Backend mund të kërkojë vërtetimin e vet edhe kur APM e konsideron përdoruesin të hyrë. Integrimi SSO i mbështetur e vendos atë raport për ju, por pranimi i hyrjes në portal nuk bën që çdo aplikacion të pranojë të njëjtat kredenciale ose të njëjtin cookie sesioni. Nëse SSO nuk është konfiguruar për burimin, aplikacioni do të kërkojë hyrjen e vet brenda një portali tashmë të vërtetuar.

Çaktivizimi i SSO për të ndryshuar nxitjen e dukshme është një shkurtore e zakonshme dhe e dobët: ndryshon dizajnin e vërtetimit pa prekur ciklin e jetës që prodhoi nxitjen. Vendosni në vend të kësaj nëse hyrja e backend duhet të shfaqet fare, dhe nëse duhet, bëjeni pjesë eksplicite të rrjedhës së publikuar.

Kontrolli 3: ka dy orë, dhe nuk janë e njëjta orë

Profili i qasjes së APM mban një afat pasiviteti dhe jetëgjatësinë maksimale të sesionit. Aplikacioni mban kohëmatësin e vet të papunësisë dhe skadimin e cookie-t. Zgjatja e kohëmatësit të portalit nuk e zgjat sesionin e aplikacionit, dhe shkurtimi i sesionit të aplikacionit nuk e shkëput përdoruesin nga portali.

Telefonata klasike e ndihmës lind nga një çift që nuk përputhet: portali është ende i vlefshëm, sesioni i aplikacionit nuk është, dhe përdoruesi sheh një formular hyrjeje që duket se kundërshton portalin. Ky është sjellje e saktë, jo defekt, dhe zgjidhja është të zgjidhni cila orë duhet të skadojë e para për këtë aplikacion.

Kontrolli 4: shkëputja ka një shtrirje të përcaktuar

Shkruani çfarë duhet të përfundojë butoni i daljes së aplikacionit: vetëm atë aplikacion, të gjithë sesionin APM, ose një sesion më të gjerë të ofruesit të identitetit. Profili i qasjes mbështet një listë URI-esh daljeje me një vonesë opsionale, dhe kështu e bëni daljen e aplikacionit të përfundojë sesionin e portalit kur kjo është kërkesa. Pa të, dalja e aplikacionit e lë portalin gjallë, dhe një kërkesë pasuese mund ta fusë përdoruesin përsëri në heshtje.

Merrni parasysh efektin mbi burimet e tjera në të njëjtin portal. Nëse dalja nga një aplikacion përfundon sesionin e gjashtë të tjerëve, përdoruesit do ta quajnë gabim, përveç nëse sjellja është rënë dakord më parë me pronarin e aplikacionit. Mbyllja e një skede dhe kthimi në webtop nuk janë provë që diçka përfundoi.

Kontrolli 5: aplikacioni i mbijeton rishkrimit

Portal Access rishkruan përmbajtje web të zgjedhur, dhe rishkrimi ka anë. Veçoritë moderne në anën e klientit, punëtorët në sfond, rrjedhat e ngarkimit dhe hyrja federale mund të bien jashtë asaj që trajton një version i caktuar. Matrica e përputhshmërisë sipas versionit e F5 është dokumenti që duhet lexuar përpara se të angazhoheni, sepse kufijtë varen nga versioni.

Testoni rrjedhat që kanë rëndësi, jo faqen e uljes: hyni, lëvizni nëpër çdo funksion të kërkuar, ngarkoni skedarë nëse aplikacioni e bën, lini sesionin e synuar të skadojë dhe ndiqni çdo rrugë daljeje. Një faqe që jepet një herë nuk është provë që aplikacioni funksionon.

Kur një rrjedhë e kërkuar nuk mund të rishkruhet, kaloni në një dizajn të dokumentuar federacioni, proxy të kundërt ose qasjeje rrjeti. Një portal shfletuesi që i kërkohet të sillet si një tunel i përgjithshëm do ta kalojë demonstrimin dhe do të dështojë në auditim.