APM-portaltagong: wa besit de sesje fan de applikaasje?
Fiif kontrôles foar in publikaasjebeslút mei BIG-IP Portal Access: omfang fan de boarne, backend-sesje, twa timers, betsjutting fan útlogge en grinzen fan it werskriuwen.
In ynternetapp fia BIG-IP APM Portal Access publisearje is in beslissing oer sesjes, net oer it kopiearjen fan in firtuele tsjinner. It portaal lit de brûker yn, it werskriuwprofyl hâldt selektearre oanfragen op it paad fan de gateway, en de applikaasje hat noch hieltyd in eigen sesje. Fiif kontrôles skiede in ûntwerp dat foarsisber gedraacht fan ien wêr't de helpdesk oer timeouts brûker foar brûker leart. Wurkje se yn folchoarder troch en stop by de earste dy't net wier is.
Kontrôle 1: de boarne is publisearre, net allinnich keppele
In blêdwizer yn de webtop bewiist dat in brûker in ynstap sjocht. It bewiist net dat de applikaasje publisearre is. Sykje it tagongsprofyl, it werskriuwprofyl en de firtuele tsjinner dy't se kombinearret, en befêstigje dan dat de boarntotaak wiist nei de applikaasje dy'tsto tinkst. As ien fan dy trije ûntbrekt of tsjinstridich is, is de rest fan de list sûnder betsjutting.
It gefal fan heal publisearre sjocht der sûn út by it yngongspunt. De firtuele tsjinner draacht it tagongsprofyl wylst it werskriuwprofyl beheind is ta in oare boarne-URI, sadat de webtop-ynstap ferskynt en de earste side laden wurdt, dêrnei ferlitte de oanfragen fan it subpaad it paad fan de gateway en berikke se de backend direkt. It spegelbyld is in boarne dy't oan de ferkearde applikaasje tawiisd is: de blêdwizer iepenet, en hy iepenet eat dat nimmen goedkard hat.
Kontrôle 2: de backend-sesje is in aparte tastân
De backend kin syn eigen autentikaasje easkje sels wylst APM de brûker as oanmeld beskôget. In stipe SSO-ynset stelt dy relaasje foar dy fêst, mar it oanmelden by it portaal akseptearje makket net dat elke applikaasje deselde oanmeldgegevens of deselde sesjekoekje akseptearret. As SSO net foar de boarne konfigurearre is, sil de applikaasje syn eigen oanmelding freegje binnen in al autentisearre portaal.
SSO útskeakelje om de sichtbere oanfreging te feroarjen is in gewoane en minne flugge wei: it feroaret it ûntwerp fan de autentikaasje sûnder de libbenssyklus oan te reitsjen dy't de oanfreging makke hat. Beskiede leaver oft de backend-aanmelding hielendal ferskine moat, en as dat sa is, meitsje der dan in eksplisyt diel fan de publisearre stream fan.
Kontrôle 3: der binne twa klokken, en it binne net deselde klok
It tagongsprofyl fan APM draacht in ynaktiviteit-timeout en in maksimum sesjeduor. De applikaasje draacht syn eigen idle-timer en it ferrinnen fan it koekje. In portaltimer ferlingje ferlinget gjin applikaasjesesje, en in applikaasjesesje ferkoartsje logt de brûker net út it portaal.
| 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 |
De klassike helpdesk-oprop komt út in pear dat net past: it portaal is noch jildich, de applikaasjesesje net, en de brûker sjocht in oanmeldformulier dat it portaal skynber tsjinspeket. Dat is korrekt gedrach, net in stoaring, en de oplossing is te kiezen hokker klok foar dizze applikaasje earst ferrinne moat.
Kontrôle 4: útlogge hat in definiearre omfang
Skriuw op wat de útlogknop fan de applikaasje einigje moat: allinnich dy applikaasje, de hiele APM-sesje, of in bredere sesje fan de identiteitsleveransier. It tagongsprofyl stipet in list fan útlog-URI's mei in opsjonele fertraging, en sa makkest dat de útlog fan de applikaasje de portaalsesje einiget as dat de eask is. Sûnder dat lit de útlog fan de applikaasje it portaal libje, en in folgjende oanfraach kin de brûker stil wer oanmelde.
Rekkenje mei it effekt op oare boarnen yn itselde portaal. As útlogge fan ien applikaasje de sesje fan seis oaren einiget, sille brûkers dat in bug neame, útsein as it gedrach earst mei de eigner fan de applikaasje ôfsprutsen is. In ljep slute en weromgean nei de webtop binne gjin bewiis dat eat einige is.
Kontrôle 5: de applikaasje oerlibbet it werskriuwen
Portal Access werskriuwt selektearre webynhâld, en werskriuwen hat rânen. Moderne funksjes oan de kliïntkant, eftergrûnwurkers, upload-streams en federearre oanmelding kinne bûten it berik falle dat in bepaalde ferzje oan kin. De ferzje-bûne kompatibiliteitsmatriks fan F5 is it dokumint dat jo lêze moatte foardat jo jo ferbine, want de grinzen binne ferzje-spesifyk.
Test de streams dy't ta sizze, net de lâningsside: meld oan, navigearje troch elke fereaske funksje, upload as de app uploadt, lit de bedoelde sesje ferrinne en folgje elk útlogpaad. In side dy't ien kear rendert is gjin bewiis dat de applikaasje wurket.
As in fereaske stream net werskreaun wurde kin, gean dan nei in dokumintearre federaasje-, reverse-proxy- of netwurktagongsûntwerp. In browserportaal dat frege wurdt him as in algemiene tunnel te gedragen sil de demo helje en de audit misse.