2008-09-17 11 views
22

Domyślnie tomcat tworzy plik cookie sesji dla bieżącej domeny.Najlepszy sposób zezwalania na pliki cookie sesji podsieci przy użyciu Tomcat

Jeśli korzystasz z witryny www.example.com, plik cookie zostanie utworzony dla witryny www.example.com (działa tylko w witrynie www.example.com). Natomiast dla domeny example.com zostanie utworzone dla .example.com (pożądane zachowanie, będzie działało na dowolnej poddomenie example.com, a także samej example.com).

Widziałem kilka zaworów Tomcat, które zdają się przechwytywać tworzenie plików cookie sesji i utworzyć zastępczy plik cookie z prawidłową domeną .example.com, jednak żadne z nich nie działa bezbłędnie i wszystkie wydają się opuszczać istniejący plik cookie i po prostu utwórz nowy. Oznacza to, że z każdym żądaniem wysyłane są dwa pliki cookie JSESSIONID.

Zastanawiam się, czy ktoś ma ostateczne rozwiązanie tego problemu.

Odpowiedz

1

Wpadłem na to za $ DAYJOB. W moim przypadku chciałem zaimplementować logowanie SSL, a następnie przekierować na stronę inną niż SSL. Podstawowym problemem w tomcat jest metoda (z pamięci) SessionManager.configureSessionCookie, która koduje wszystkie zmienne, do których chcesz uzyskać dostęp.

Wymyśliłem kilka pomysłów, w tym szczególnie skandaliczny hack przy użyciu mod_headers w Apache, aby przepisać cookie na podstawie substytucji regex.

Ostatecznym sposobem rozwiązania tego problemu jest przesłanie łaty programistom tomcat, które dodadzą konfigurowalne parametry do klasy SessionManager.

1

Jako że sesja (i jej identyfikator) jest zasadniczo uważana za wartość tylko dla aplikacji wydającej, można raczej szukać ustawienia dodatkowego pliku cookie. Spójrz na Tomcats SingleSignOnValve, dostarczając dodatkowy plik cookie JSESSIONIDSSO (zwróć uwagę na ... SSO) dla ścieżki serwera "/" zamiast "/ nazwa_aplikacji" (ponieważ zazwyczaj ustawiane są pliki cookie JSESSIONID).

Za pomocą takiego zaworu można wdrożyć dowolną komunikację międzyprocesową, której potrzebujesz, aby zsynchronizować dowolny stan między różnymi serwerami, hostami wirtualnymi lub aplikacjami internetowymi na dowolnej liczbie kamer/serwerów sieci web/cokolwiek.

Innym powodem, dla którego nie można użyć pliku cookie sesji dla własnych celów, jest to, że wiele aplikacji internetowych na tym samym hoście ma różne identyfikatory sesji. Na przykład. istnieją różne pliki cookie dla "/ webapp1" i "/ webapp2". Jeśli podasz plik cookie "/ webapp1" do "/ webapp2", nie znajdzie to sesji, do której się odwołujesz, unieważni sesję + cookie i ustawi nową. Trzeba będzie przepisać wszystkie operacje sesji tomcats, aby zaakceptować wartości zewnętrznych identyfikatorów sesji (zły pomysł w kontekście bezpieczeństwa) lub udostępnić określony stan pomiędzy aplikacjami.

Obsługa sesji powinna być traktowana jako biznes kontenerów (tomcats). Niezależnie od tego, czego potrzebujesz, powinieneś dodać, nie ingerując w to, co kontener uważa za konieczne.

1

Techniki zaworu nie wydają się być w 100% doskonałe. Jeśli odważysz się zmodyfikować sam Tomcat:

catalina.jar zawiera następujące klasy: org.apache.catalina.connector.Zapytanie

kupna metodę:

configureSessionCookie(Cookie cookie) 

dla naszego środowiska, że ​​najlepiej po prostu zakodować, ale można to zrobić bardziej fantazyjne logikę:

cookie.setDomain(".xyz.com"); 

Wydaje się doskonale działa. Byłoby miło, gdyby to było konfigurowalne w tomcat.

6

Właśnie przeszedł przez to wszystko szuka prostego rozwiązania. Zacząłem najpierw przyglądać się temu z perspektywy kocurka.

Tomcat nie daje bezpośredniego dostępu do konfiguracji pliku cookie domeny dla sesji, a ja na pewno nie chciałem dostosowywać tomcat, aby rozwiązać ten problem, jak pokazano w innych postach.

Zawory w tomcat również wydają się być problemem z uwagi na ograniczenia dostępu do nagłówków. Pliki cookie są wbudowane w specyfikację serwletu. Zawodzą też całkowicie, jeśli odpowiedź HTTP zostanie zatwierdzona, zanim zostanie przekazana do twojego zaworu.

Odkąd wykonaliśmy nasze żądania za pośrednictwem Apache, przeszedłem do tego, jak użyć Apache, aby rozwiązać problem.

Najpierw wypróbowałem dyrektywę mod_proxy ProxyPassReverseCookieDomain, ale nie działa ona dla plików cookie JSESSIONID, ponieważ tomcat nie ustawia atrybutu domeny, a ProxyPassReakeCookieDomain nie może działać bez domeny, która jest częścią pliku cookie.

Natknąłem się również na hakowanie za pomocą ProxyPassReverseCookie Path, gdzie przepisywano ścieżkę, aby dodać atrybut domeny do pliku cookie, ale to było dość kłopotliwe dla strony produkcyjnej.

W końcu udało mi się to zrobić, przepisując nagłówki odpowiedzi za pomocą modułu mod_headers w apache, o czym wspomniał Dave powyżej.

I dodano następującą linię wewnątrz definicji wirtualnego hosta:

Header edit Set-Cookie "(JSESSIONID\s?=[^;,]+?)((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(;\s?(?:(?i)Domain\s?=)[^;,]+?)?((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(,|$)" "$1$2; Domain=.example.com$4$5" 

Powyższy powinny być w jednej linii w konfiguracji. Zastąpi dowolny atrybut domeny cookie JSESSIONID nazwą ".example.com". Jeśli plik cookie JSESSIONID nie zawiera atrybutu domeny, wzorzec doda taki plik o wartości ".example.com". Jako bonus, rozwiązanie to nie cierpi z powodu problemu z podwójnymi plikami cookie JSESSION zaworów.

Wzór powinien działać z wieloma plikami cookie w nagłówku pliku cookie, nie wpływając na inne pliki cookie w nagłówku. Powinna również istnieć możliwość modyfikacji do pracy z innymi ciasteczkami poprzez zmianę JSESSIONID w pierwszej części wzorca na dowolną nazwę ciasteczka, której pragniesz.

Nie jestem użytkownikiem energii, więc jestem pewny, że istnieje kilka optymalizacji, które można wprowadzić do schematu, ale wydaje się, że działa on dla nas do tej pory.

Będę aktualizować ten post, jeśli znajdę jakieś błędy ze wzorem. Mam nadzieję, że to powstrzyma kilku z was, którzy musieli przejść przez kilka ostatnich dni frustracji, tak jak ja.

Powiązane problemy