Play2 Framework - brak sesji. Dlaczego?

Play2 Framework - brak sesji. Dlaczego?
krzysiek050
krzysiek050
krzysiek050
krzysiek050
  • Rejestracja:ponad 12 lat
  • Ostatnio:ponad 4 lata
  • Postów:1272
0

Hej.

Play2 ma podejście pełnej bezstanowości po stronie serwera, co wiąże się z brakiem sesji. Braki są trochę na siłę załatane podpisanym ciachem, czyli stanowość jednak jest, ale nie po stronie serwera.

I moje pytanie brzmi: Dlaczego zastosowali takie podejście? W czym jest ono lepsze od stosowania sesji?
Ja rozumiem że w http jest w założeniu bezstanowy, ale to było projektowane bardzo dawno temu. Teraz wszędzie jest logowanie czyli stanowość i nikt nie ma z tym problemu. Więc jaki jest plus takiego założenia?

Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
n0name_l
n0name_l
n0name_l
n0name_l
  • Rejestracja:ponad 12 lat
  • Ostatnio:prawie 5 lat
  • Postów:2412
1

Teraz wszędzie jest logowanie czyli stanowość i nikt nie ma z tym problemu.

W Play tez przeciez jest i tez nikt nie ma z tym problemu. :\

Więc jaki jest plus takiego założenia?

Skalowalnosc.

Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
krzysiek050
krzysiek050
krzysiek050
krzysiek050
  • Rejestracja:ponad 12 lat
  • Ostatnio:ponad 4 lata
  • Postów:1272
0

Ok. Ale w play jest stan trzymany w ciachu, czyli i tak jest ta informacja trzymana, przekazywana i znana. W czym to rozwiązanie poprawia skalowalność w porównaniu do podejścia z sesją? Przecież rozwiazania JEE/Spring też są uważane za bardzo skalowalne a posiadają mechanizm sesji.

Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
airborn
airborn
airborn
airborn
  • Rejestracja:prawie 16 lat
  • Ostatnio:około 7 lat
  • Postów:274
1
krzysiek050 napisał(a):

Teraz wszędzie jest logowanie czyli stanowość

Nie, logowanie i stanowość to dwie zupełnie rzeczy i niekoniecznie powiązane ze sobą. Cały REST opiera się na bezstanowości, po prostu każde żądanie zawiera dane niezbędne do uwierzytelnienia użytkownika.

Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
krzysiek050
krzysiek050
krzysiek050
krzysiek050
  • Rejestracja:ponad 12 lat
  • Ostatnio:ponad 4 lata
  • Postów:1272
0

No ok. Rozumiem to. Ale to jest tylko filozofia. Efekt jest przecież ten sam, czyli znam tożsamość użytkownika. Za to takie rozwiązanie posiada minusy:

  • Nie mogę nic ukryć przed użytkownikiem.
  • Sprawdzanie podpisu per request - zapewne wolniejsze niż powiązanie jsessionid z danymi.
Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
airborn
airborn
airborn
airborn
  • Rejestracja:prawie 16 lat
  • Ostatnio:około 7 lat
  • Postów:274
1

Nie bardzo rozumiem, czego nie możesz ukryć.

krzysiek050
Danych które nie są publiczne jeżeli jest to na protokole http.
airborn
No jak to nie, masz jakiś rodzaj filtru, który uwierzytelnia użytkownika, jeżeli brak nagłówków uwierzytelniających, lub dane są nieprawidłowe po prostu zwracasz status 401 Unauthorized. Ew. gdy nie chcesz żeby użytkownik w ogóle wiedział, że taki zasób istnieje to mapujesz sobie taki wyjątek/status na 404
Koziołek
A jak jesteś wredny to zwracasz 418 :)
krzysiek050
Chodzi mi o to że dane które wysyłasz w ciastku są podpisywane ale nieszyfrowane. Czyli user wie co przechowuje a jeżeli leci po http a nie https to nawet nie tylko user może wiedzieć. W sesji znasz jakiś ciąg identyfikujący sesję ale on nic specjalnego nie mówi.
airborn
Ale ja nie mówię o żadnym ciastku. Klient zna swój login i hasło (token, cokolwiek) i wysyła je w każdym requeście. Klient i tak i tak zna swoje hasło ;)
krzysiek050
Chodzi mi o sytuację. Robię sklep internetowy i koszyk. W play2 zawartosc koszyka wysyłam z każdym żądaniem. Jeżeli korzystam z jakiegoś osiedlowego lana a stronka jest bez szyfrowania ruchu to admin dowie się że kupuję DIRTY_SCHOOLGIRL_COSTUME :)
airborn
To nie wysyłaj stanu koszyka za każdym razem. Stwórz koszyk, zwróć jego ID, dodaj do koszyka o znanym ID towary o znanych ID, zapłać za koszyk o znanym ID. Tak działa cały REST.
krzysiek050
Ale wtedy powstanie coś ala serializacja sesji którą opisał Koziołek niżej. Dodatkowo sam będę musiał tym zarządzać.
Koziołek
Niekoniecznie. Serializacja o ktorej mówię dotyczy CAŁEJ sesji wraz z przyległościami. Tu serializujesz tylko część biznesową. Zresztą jakoś koszyk przechowywać musisz w takim modelu (baza danych) zatem i tak mechanizm musisz w jakiś sposób napisać.
krzysiek050
A jakie przyległości zawiera np. Spring? Tzn nawet dla tego przykladu, co oprócz koszyka i username. A koszyka nie musiałbym tworzyć gdybym miał go w sesji i po akceptacji wrzucał prosto jako zamówienie.
Koziołek
na przykład atrybuty sesji (z kontenera), listenery, kontekst itp. Pamiętaj, że ty widzisz w swoim kodzie tylko "użyteczną" część frameworku, bez bebechów.
krzysiek050
Ok. Dzięki wam za dyskusję. Trochę mi w głowie pojasniało :).
Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
Koziołek
Koziołek
Koziołek
Koziołek
Moderator
  • Rejestracja:około 18 lat
  • Ostatnio:2 dni
  • Lokalizacja:Stacktrace
  • Postów:6822
2

Nie jest ten sam. Sprawdzanie podpisu per request choć wolniejsze (ciekawe o ile) pozwala na znacznie lepszy loadbalacing całego rozwiazania. W klasycznym podejściu gdy masz cluster loadbalacer musi:
a) kierować danego użytkownika na konkretny serwer na którym się zalogował i który ma jego sesję w pamięci. Wada - jak serwer padnie to sesja razem z nim.
b) każdorazowo zapisywać i odtwarzać stan sesji z np. bazy danych jeżeli kieruje do "pierwszego wolnego". Wada - serializacja sesji jest strasznie powolna...

Brak sesji w taki sposób jak realizuje to Play2 łączy zalety klasycznych podejść tzn. masz failover, skalowalność horyzontalną i ogólnie zapewnienie "ciągłości działania" jednocześnie zapewniajac bardzo sprawną obsługę autoryzacji i autentykacji.

Sięgam tam, gdzie wzrok nie sięga… a tam NullPointerException
Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
krzysiek050
krzysiek050
krzysiek050
krzysiek050
  • Rejestracja:ponad 12 lat
  • Ostatnio:ponad 4 lata
  • Postów:1272
0

Bardzo rzeczowa odpowiedz. Dzieki :).

Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.

Utwórz konto