Torej obstaja tista zapletena heterogena spletna aplikacija z deli AJAX, ki so narejeni ročno in z ogrodji, več pojavnih oken itd. Veliki ugleden odjemalec se obrne na vas z zahtevo, da razveljavi, zapre ali izvede katero koli drugo dejavnost na celotnem spletu okna aplikacij, ko seja HTTP poteče. Upajmo, da veste, kako nadzirati interval zakasnitve seje HTTP, saj se za spletno aplikacijo, skladno z J2EE, to naredi iz datoteke web.xml (vendar v številnih strežnikih aplikacij to ni običajno). Za 10-minutni premor je:
10 Zahteva odjemalca sploh ni absurdna in je z vidika končnega uporabnika povsem smiselna, vendar lahko za razvijalca postane strašna bolečina, ker: 1. Odštevalnika ne morete preprosto zagnati v oknu brskalnika vsakič, ko se naloži stran da zaprete okno ob izteku časa. Ta pristop je deloval v svetu, ki ni AJAX, ko je vsaka interakcija brskalnika in strežnika povzročila, da se okno brskalnika ponovno naloži. 2. Strežnika ne morete poizvedovati, ali je seja HTTP potekla ali ne, saj bo vsaka taka poizvedba obravnavana kot interakcija med brskalnikom in strežnikom, ki podaljša sejo. To bo vodilo do seje, ki se nikoli ne izteče. 3. Lahko ustvarite ločeno spletno aplikacijo, ki se zaveda seje primarne spletne aplikacije HTTP in seka z njo. Toda to je presežek in verjetnost, da bo takšna rešitev sprejeta, je zelo majhna zaradi težav z integracijo, ki bi se lahko pojavile. 4. Lahko poskusite prestreči vse interakcije brskalnika in strežnika AJAX z neko napredno kodo, podobno vdoru, in to vam bo pomagalo pri soočanju s trenutnim oknom. Toda to ne deluje v primeru več odprtih oken - preprosto ne morete komunicirati med okni brskalnika. Edini način za pogovor z nekaterim odprtim oknom iz primarnega je uporaba sklica JavaScript na drugo okno, in ko je primarno okno ponovno naloženo ali usmerjeno na drugo mesto, izgubi vse sklice JavaScript na druga okna. 5. Najbolj realističen pristop je, da periodično pošiljate zahteve XMLHTTP JavaScript (iz vsakega odprtega okna) na strežnik vsako {max max neaktivni interval} +10 sekund. To bo sčasoma zaprlo vsa okna, vendar lahko povzroči, da bodo okna zaprta v minutah (ali celo urah, odvisno od nastavitve časovne omejitve seje spletne aplikacije), potem ko se seja HTTP uniči, npr. ko se uporabnik odjavi iz primarnega okna. Ni več možnosti, razočarani ste in mislite, da je pravi čas, da jutri vzamete očetovo pištolo in ustrelite sošolce v šoli. Ne, še ne otrok - izhod še obstaja! Izhod ni zelo enostaven, je pa zelo eleganten. Piškotki nam bodo v pomoč. Lahko bi pomislili, da bi čas uporabe piškotkov naredil trik. Na žalost, kot je opisano v
to
V članku se ne morete zanesti na čas trajanja piškotkov, saj ga meri brskalnik odjemalca in nihče ne more zagotoviti, da odjemalska sistemska ura ne zaostaja eno leto. Tukaj je sistem in metoda za sledenje časovnim omejitvam seje HTTP v heterogenih spletnih aplikacijah. Na vsako zahtevo brskalnika do strežnika s filtrom strežnika nastavi dva piškotka. Ena zadrži trenutni čas strežnika, druga pa čas poteka seje. Trenutni čas strežnika je potreben samo za izračun odmika med odjemalcem in strežnikom. Nato se čas izteka seje redno preverja glede na _računani_ trenutni čas strežnika (ne pozabite na odmik). Vsakič, ko na strežnik vložijo _ katero koli zahtevo, se piškotek s časom izteka posodobi in vse skupaj preprosto deluje. V praksi se ta metoda izvaja v samo treh korakih: 1. Ustvarite filter strežnika, ki bo filtriral vsako zahtevo do vaše spletne aplikacije. Konfigurirajte ga v web.xml tako:
SessionTimeoutCookieFilter some.package.SessionTimeoutCookieFilter SessionTimeoutCookieFilter / * Ne skrbite zaradi uspešnosti svoje spletne aplikacije - ta filter je ZELO primitiven, v odgovor pa doda samo dva piškotka:
javna praznina doFilter (zahtevek ServletRequest, ServletResponse resp, FilterChain filterChain) vrže IOException, ServletException {HttpServletResponse httpResp = (HttpServletResponse) resp; HttpServletRequest httpReq = (HttpServletRequest) req; dolg currTime = System.currentTimeMillis (); long expiryTime = currTime + session.getMaxInactiveInterval () * 1000; Piškotek piškotek = nov piškotek ("serverTime", "" + currTime); cookie.setPath ("/"); httpResp.addCookie (piškotek); if (httpReq.getRemoteUser ()! = null) {piškotek = nov piškotek ("sessionExpiry", "" + expiryTime); } else {piškotek = nov piškotek ("sessionExpiry", "" + currTime); } cookie.setPath ("/"); httpResponse.addCookie (piškotek); filterChain.doFilter (req, resp); } Pot nastavitve (v našem primeru na "/") je zelo pomembna. Če nastavitev poti izpustite, jo bo brskalnik samodejno izračunal iz URL-ja, kar bo povzročilo kaos v shrambi piškotkov vašega brskalnika. 2. Za izračun odmika med časom strežnika in odjemalca potrebujemo majhen JavaScript v vsakem oknu. Zagnati ga je treba samo enkrat, vendar ne bi škodilo, če bi ga zagnali ob vsakem nalaganju strani:
funkcija calcOffset () {var serverTime = getCookie ('serverTime'); serverTime = serverTime == null? null: Math.abs (serverTime); var clientTimeOffset = (nov datum ()). getTime () - serverTime; setCookie ('clientTimeOffset', clientTimeOffset); } window.onLoad = function () {calcOffset (); }; 3. In na koncu potrebujemo funkcijo, ki bi dejansko preverila, ali je seja potekla. Izvajati ga je treba redno, v našem primeru vsakih 10 sekund (ali 10000 milisekund):
funkcija checkSession () {var sessionExpiry = Math.abs (getCookie ('sessionExpiry')); var timeOffset = Math.abs (getCookie ('clientTimeOffset')); var localTime = (nov datum ()). getTime (); if (localTime - timeOffset> (sessionExpiry + 15000)) {// 15 dodatnih sekund, da se prepričate, da window.close (); } else {setTimeout ('checkSession ()', 10000); }} Zapiranje oken brskalnika po izteku seje je čisto brutalno in ga lahko in mora spremljati opozorilno sporočilo, ki se pojavi približno 1 minuto pred iztekom seje. Resnično me zanima vaše
kritične povratne informacije
o moji metodi.
To zgodbo "Sledenje poteku seje v brskalniku" je prvotno objavil JavaWorld.
