[ Pobierz całość w formacie PDF ]
.Apletowe œledzenie sesjiNiemal ka¿dy serwer obs³uguj¹cy aplety wdra¿a œledzenie sesji oparte na„Ciasteczkach”, gdzie identyfikacja sesji jest zapisywana po stronie klienta wtrwa³ym cookie.Serwer odczytuje ID sesji z cookie JSESSIONID, a nastêpniedeterminuje który obiekt sesji uczyniæ dostêpnym podczas ka¿dego zlecenia.Dla klientów apletu taka sytuacja mo¿e przedstawiaæ problem.Wiêkszoœæœrodowisk apletowych wdra¿a HttpURLConnection w taki sposób, ¿e kiedy aplettworzy po³¹czenie HTTP, œrodowisko automatycznie dodaje zawieraj¹ce cookiesprzegl¹darki, do zlecenia.Pozwala to apletowi na uczestniczenie w tej samej,co inne zlecenia przegl¹darki, sesji.Problemem jest jednak, i¿ inne œrodowiskaapletowe, takie jak starsze wersje œrodowiska „Java Plug-In enviroment” nie s¹zintegrowane z przegl¹dark¹ i dlatego zlecenia apletów jawi¹ siê jakooddzielone od normalnej sesji przegl¹darki.Rozwi¹zanie dla sytuacji, w którejaplety musz¹ dzia³aæ w podobnych œrodowiskach jest przesy³ane identyfikacjisesji do apletu oraz pozwalanie apletowi na przekazanie tego ID z powrotem doserwera, jako sztucznie utworzone cookie JSESSIONID.W rozdziale 10„Komunikacja aplet zwyk³y — aplet tworzony na serwerze” zosta³a zamieszczonaklasa HttpMessage — aby pomagaæ w tego typu sytuacjach.Aplet mo¿e otrzymaæidentyfikacjê sesji jako zwyk³y parametr apletu (dodany dynamicznie do stronyHTML zawieraj¹cej aplet).Awaryjne zmiany trybu pracy — „nie-ciasteczkowe”Specyfikacja apletu mówi, i¿ serwery WWW musz¹ obs³ugiwaæ œledzenie sesjirównie¿ dla przegl¹darek, które nie akceptuj¹ cookies, których tak wielewykorzystuje przepisywanie URL-u jako awaryjn¹ zmianê trybu pracy.Wymaga tododatkowej pomocy ze strony apletów, które generuj¹ strony zawieraj¹ce URL-e.Wcelu obs³u¿enia œledzenia sesji poprzez przepisywanie URL-u, aplet musiprzepisaæ ka¿dy lokalny URL, zanim odeœle go klientowi.Interfejs API zawieradwie metody, aby wykonaæ to zadanie: encode() oraz encodeRedirectURL():public String HttpServlrtresponse.encodeURL(String url)Metoda ta koduje (przepisuje) okreœlony URL aby do³¹czyæ ID sesji, a nastêpnieodsy³a nowy URL lub, je¿eli kodowanie nie jest potrzebne albo nie obs³ugiwane,pozostawia URL niezmienionym.Zasady decyduj¹ce o tym kiedy i jak ma byæzakodowany URL s¹ domen¹ serwera.Wszystkie URL-e wychodz¹ce z serwera, powinnybyæ uruchamiane poprzez t¹ w³aœnie metodê.Zwróæmy uwagê, i¿ metoda encodeURL()mog³aby byæ bardziej precyzyjnie nazwana rewriteURL() — aby nie myli³a siê zprocesem kodowania URL-u, który koduje specjalne znaki w strumieniu URL-u.public String HttpServlrtresponse.encodeRedirectURL(String url)Metoda ta koduje (przepisuje) okreœlony URL aby do³¹czyæ identyfikacjê sesji, anastêpnie odsy³a nowy URL lub, je¿eli kodowanie nie jest potrzebne albo nieobs³ugiwane — pozostawia URL niezmienionym.Zasady decyduj¹ce o tym kiedy i jakma byæ zakodowany URL s¹ domen¹ serwera.Metoda ta mo¿e u¿ywaæ odmiennych zasadni¿ metoda encodeURL().Wszystkie URL-e przekazane do metodyHttpServletResponse — sendDirect(), powinny byæ uruchamiane poprzez t¹ metodê.Poni¿szy fragment kodu ukazuje aplet pisz¹cy ³¹cznik do samego siebie, któryjest kodowany tak, aby zawiera³ bie¿¹c¹ identyfikacjê sesji:out.println("Click here");out.println("aby powtórnie za³adowaæ t¹ stronê.");Na serwerach, które nie obs³uguj¹ przepisywania URL-u lub maj¹ wy³¹czon¹ t¹funkcjê, koñcowy URL pozostaje bez zmian.Poni¿ej przedstawiamy fragment kodu,na którym jest zaprezentowany aplet przekierowuj¹cy u¿ytkownika do URL-uzakodowanego tak, aby zawiera³ ID sesji:res.sendRedirect(res.encodeRedirectURL("/servlet/NewServlet")) ;Aplet jest w stanie wykryæ czy identyfikacja sesji, wykorzystywana dozidentyfikowania aktualnego obiektu HttpSession, pochodzi od cookie czy odzakodowanego URL-u wykorzystuj¹cego metody isRequestedSessionIdFromCookie() iisRequestedSessionIdFromURL():public boolean HttpServletRequest.isRequestedSessionIdFromCookie()public boolean HttpServletRequest.isRequestedSessionIdFromURL()Okreœlenie czy identyfikacja sesji pochodzi z innego Ÿród³a, takiego jak sesjaSSL, nie jest aktualnie mo¿liwe.ID sesji bêd¹ce przedmiotem zlecenia mo¿e nie pokrywaæ siê z identyfikacj¹sesji, odes³an¹ przez metodê getSession(), tak jak ma to miejsce kiedy ID sesjijest niewa¿ne.Aplet mo¿e jednak ustaliæ czy identyfikacja sesji bêd¹caprzedmiotem zlecenia jest wa¿na, przy pomocy metodyisRequestedSessionIdValid():public boolean HttpServletRequest
[ Pobierz całość w formacie PDF ]