Na jakich warunkach powstaje JSESSIONID?

276

Kiedy / jakie są warunki JSESSIONIDutworzenia a?

Czy to na domenę? Na przykład, jeśli mam serwer aplikacji Tomcat i wdrażam wiele aplikacji internetowych, czy zostanie utworzona inna w zależności JSESSIONIDod kontekstu (aplikacji internetowej), czy też jest ona udostępniana aplikacjom internetowym, o ile są one tej samej domeny?

java jsessionid

— joshjdevl
źródło

324

Plik cookie JSESSIONID jest tworzony / wysyłany podczas tworzenia sesji. Sesja jest tworzona przy pierwszym wywołaniu kodu request.getSession()lub request.getSession(true)po raz pierwszy. Jeśli chcesz tylko uzyskać sesję, ale nie utworzyć jej, jeśli nie istnieje, użyj request.getSession(false)- spowoduje to zwrócenie sesji lub null. W takim przypadku nowa sesja nie jest tworzona, a ciasteczko JSESSIONID nie jest wysyłane. (Oznacza to również, że sesja nie musi być utworzony na pierwsze żądanie ... Ty i Twój kod są pod kontrolą , gdy sesja jest tworzony)

Sesje są dostosowane do kontekstu:

SRV.7.3 Zakres sesji

Obiekty HttpSession muszą mieć zasięg na poziomie aplikacji (lub kontekstu serwletu). Mechanizm bazowy, taki jak plik cookie użyty do ustanowienia sesji, może być taki sam dla różnych kontekstów, ale obiekt, do którego się odwołuje, w tym atrybuty w tym obiekcie, nigdy nie może być współużytkowany przez konteksty przez kontener.

( Specyfikacja Servlet 2.4 )

Aktualizacja: każde wywołanie strony JSP domyślnie tworzy nową sesję, jeśli jeszcze jej nie ma. Można to wyłączyć za pomocą session='false'dyrektywy strony, w którym to przypadku zmienna sesji nie jest w ogóle dostępna na stronie JSP.

— Peter Štibraný
źródło

2

nie można utworzyć sesji bez wyraźnego wywołania getSession? jeśli chodzi o „nigdy nie może być dzielony między kontekstami przez kontener”, websphere ma opcję udostępniania sesji, co jest motywacją do pytania :)

— joshjdevl

Nie, jeśli używasz tylko Servlet API. Mogą jednak istnieć rozszerzenia specyficzne dla serwera (jak wspominacie udostępnianie sesji Websphere).

— Peter Štibraný

Wierzę, że Twój plik context.xml może kontrolować automatyczne tworzenie sesji, jeśli tag <Context> zawiera atrybut cookie, np. <Context cookies = "false">

— BT

W tej chwili otrzymuję wiele trafień w moim filtrze, aby utworzyć sesję i wydaje się, że jest to dopiero po drugim trafieniu (nie odświeżeniu drugiej strony), które jest tworzone, to nazywa się moją uwagą „sesja niekoniecznie jest tworzona na pierwsze żądanie…” to to powiązane? czy możesz podać przykład, dlaczego niekoniecznie jest to tworzone na pierwsze żądanie? Dzięki!

— jpganz18

@ jpganz18: Jeśli po prostu zadzwonisz request.getSession()lub request.getSession(true), uzyskasz istniejącą lub nową sesję. Jednak jeśli twój kod wywołuje request.getSession(false), to albo masz istniejącą sesję, albo zerową, jeśli nie istnieje żadna sesja.

— Peter Štibraný

49

Oto informacje o jeszcze jednym źródle JSESSIONIDpliku cookie:

Właśnie debugowałem jakiś kod Java, który działa na serwerze tomcat. request.getSession()Nigdzie nie dzwoniłem jawnie w kodzie, ale zauważyłem, że JSESSIONIDplik cookie wciąż jest ustawiony.

W końcu przyjrzałem się wygenerowanemu kodowi Java odpowiadającemu JSP w katalogu roboczym pod Tomcat.

Wygląda na to, że niezależnie od tego, czy ci się spodoba, czy nie, jeśli wywołasz JSP z serwletu, JSESSIONIDzostanie utworzony!

Dodano: Właśnie to znalazłem, dodając następującą dyrektywę JSP:

<%@ page session="false" %>

możesz wyłączyć ustawienie JSESSIONIDJSP.

— Rangachari Anand
źródło

3

Innymi słowy: domyślna wartość atrybutu sesji strony to „prawda”. Co może być nieoczekiwane w niektórych (wielu?) Przypadkach.

— David Balažic,

Używam też tomcat i wcale nie używam jsp, ale i tak tworzony jest sesyjny plik cookie. Masz pomysł, jak temu zapobiec w tej sytuacji?

— ClassyPimp,

23

KOREKTA: Głosuj na odpowiedź Petera Štibranego - jest bardziej poprawna i kompletna!

„JSESSIONID” to unikalny identyfikator sesji http - patrz javadoc tutaj . Tam znajdziesz następujące zdanie

Informacje o sesji dotyczą tylko bieżącej aplikacji WWW (ServletContext), więc informacje przechowywane w jednym kontekście nie będą bezpośrednio widoczne w innym.

Więc kiedy pierwszy raz odwiedzasz witrynę, tworzona jest nowa sesja i powiązana z SevletContext. W przypadku wdrożenia wielu aplikacji sesja nie jest udostępniana.

Możesz także unieważnić bieżącą sesję, a tym samym utworzyć nową. np. przy przejściu z http na https (po zalogowaniu), bardzo dobrym pomysłem jest utworzenie nowej sesji.

Mam nadzieję, że to odpowiada na twoje pytanie.

— Mo.
źródło

1

Jasne wyjaśnienie zakresu sesji.

— user3123690

@Mo link jest zepsuty

— Timofey,

8

Uważaj, jeśli Twoja strona zawiera inne pliki .jsp lub .jspf (fragment)! Jeśli nie ustawisz

<%@ page session="false" %>

również na nich strona nadrzędna rozpocznie nową sesję i ustawi plik cookie JSESSIONID.

W szczególności w przypadku stron .jspf dzieje się tak, jeśli plik web.xml został skonfigurowany za pomocą takiego fragmentu:

<jsp-config>
    <jsp-property-group>
        <url-pattern>*.jspf</url-pattern>
    </jsp-property-group>
</jsp-config>

aby włączyć w nich skryptlety.

— polaretto
źródło

Czy masz na myśli set page session = false we wszystkich zawartych fragmentach (.jsp i .jspf) i nie włączasz go do głównego pliku jsp zawierającego resztę fragmentów?

— Ommadawn

2

W przypadku linków wygenerowanych w JSP z niestandardowymi tagami musiałem użyć

<%@ page session="false" %>

w JSP

I

request.getSession().invalidate();

w akcji Struts

— Jerome Jaglale
źródło