APM atariaren sarbidea: nori dagokio aplikazioaren saioa?
Bost egiaztapen BIG-IP Portal Access bidez argitaratzeko erabaki baterako: baliabidearen irismena, backend saioa, bi tenporizadore, saioa ixtearen esanahia eta berridazketaren mugak.
Intraneteko aplikazio bat BIG-IP APM Portal Access bidez argitaratzea saioei buruzko erabakia da, ez zerbitzari birtual bat kopiatzeko erabakia. Atariak erabiltzailea onartzen du, berridazketa-profilak hautatutako eskaerak atearen bidean mantentzen ditu, eta aplikazioak bere saioa du oraindik. Bost egiaztapenek modu aurreikustekoan jokatzen duen diseinua bereizten dute laguntza-zerbitzuak erabiltzailez erabiltzaile timeoutak ezagutzen dituen diseinutik. Egin itzazu ordenan eta gelditu betetzen ez den lehenengoan.
1. egiaztapena: baliabidea argitaratuta dago, ez soilik estekatuta
Webtop-eko laster-marka batek erabiltzaileak sarrera bat ikusten duela frogatzen du. Ez du frogatzen aplikazioa argitaratuta dagoenik. Bilatu sarbide-profila, berridazketa-profila eta biak batzen dituen zerbitzari birtuala, eta egiaztatu baliabidearen esleipena uste duzun aplikaziora doala. Hiruretako bat falta bada edo koherentea ez bada, zerrendaren gainerakoa alferrikakoa da.
Erdi argitaratutako kasua osasuntsu dirudi sarrera-puntuan. Zerbitzari birtualak sarbide-profila darama, berridazketa-profila beste baliabide URI batera mugatuta dagoen bitartean, beraz webtop-eko sarrera agertzen da eta lehen orria kargatzen da, gero azpibideko eskaerek atariaren bidea uzten dute eta backend-era zuzenean iristen dira. Alderantzizko irudia aplikazio okerri esleitutako baliabidea da: laster-marka irekitzen da, eta inork onartu ez duen zerbait irekitzen du.
2. egiaztapena: backend saioa egoera bereizia da
Backend-ek bere autentifikazioa eskatu dezake APM-k erabiltzailea saioa hasita dagoela uste duen arren. Onartutako SSO integrazioak harreman hori ezartzen du zure ordez, baina atariko saio-hasiera onartzeak ez du lortzen aplikazio bakoitzak kredentzial berak edo cookie berbera onartzea. SSO baliabiderako konfiguratuta ez badago, aplikazioak bere saio-hasiera eskatuko du jada autentifikatuta dagoen atari baten barruan.
SSO desgaitzea ageriko galdera aldatzeagatik ohiko eta txarra den lasterbidea da: autentifikazioaren diseinua aldatzen du galdera sortu zuen bizi-zikloa ukitu gabe. Erabaki horren ordez backend-eko saio-hasierak agertu behar duen ala ez, eta behar badu, egin ezazu argitaratutako fluxuaren zati esplizitu.
3. egiaztapena: bi erloju daude, eta ez dira erloju bera
APM-ren sarbide-profilak jarduerarik ezaren timeout bat eta saioaren bizi-iraupen maximoa darama. Aplikazioak bere idle tenporizadorea eta cookiearen iraungitzea darama. Atariaren tenporizadorea handitzeak ez du aplikazioaren saioa luzatzen, eta aplikazioaren saioa laburtzeak ez du erabiltzailea ataritik ateratzen.
| 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 |
Laguntza-dei klasikoa bikote desegokitik dator: ataria oraindik baliozkoa da, aplikazioaren saioa ez, eta erabiltzaileak atariari kontraesaten diola dirudien saio-hasierako formularioa ikusten du. Portaera zuzena da, ez akatsa, eta konponbidea da zein erlojuk iraungi behar duen lehenago aplikazio honetarako.
4. egiaztapena: saioa ixteak zehaztutako irismena du
Idatzi aplikazioaren saioa ixteko botoiak zer amaitu behar duen: aplikazio hori soilik, APM saio osoa, edo identitate-hornitzailearen saio zabalagoa. Sarbide-profilak saioa ixteko URI zerrenda onartzen du atzerapen aukerakoarekin, eta horrela egiten duzu aplikazioaren saioa ixteak atariaren saioa amaitzea hori denean baldintza. Hori gabe, aplikazioaren saioa ixteak ataria bizirik uzten du, eta ondorengo eskaera batek erabiltzailea isilean sartu dezake berriro.
Kontuan hartu atari bereko beste baliabide batzuetan duen eragina. Aplikazio batetik irteteak beste sei batzuen saioa amaitzen badu, erabiltzaileek akats deituko diote, portaera lehenago aplikazioaren jabearekin adostu ez bada. Fitxa bat ixteak eta webtop-era itzultzeak ez dute ezer amaitu denik frogatzen.
5. egiaztapena: aplikazioak berridazketa gainditzen du
Portal Access-ek hautatutako web-edukia berridazten du, eta berridazketak ertzak ditu. Bezeroaren aldeko funtzio modernoak, atzeko langileak, igoera-fluxuak eta saio-hasiera federatua bertsio jakin batzuek kudeatzen dutenetik kanpo gera daitezke. F5-ren bertsioen araberako bateragarritasun-matrizea da konpromisoa hartu aurretik irakurri beharreko dokumentua, mugak bertsioaren araberakoak baitira.
Probatu axola duten fluxuak, ez harrera-orria: hasi saioa, nabigatu beharrezko funtzio bakoitzean, igo fitxategiak aplikazioak igotzen badu, utzi aurreikusitako saioa iraungitzen eta jarraitu saioa ixteko bide guztiak. Behin errendatzen den orria ez da aplikazioak funtzionatzen duen froga.
Beharrezko fluxu bat berridatzi ezin denean, joan dokumentatutako federazio, alderantzizko proxy edo sareko sarbide diseinu batera. Tuntu orokor gisa jokatzeko eskatzen zaion nabigatzaile-atari batek demoa gaindituko du eta auditoria huts egingo du.