Czy sesja internetowa jest „zła”? Dlaczego?

innego dnia rozmawiałem z kolegą, który powiedział, że używanie sesji użytkownika w aplikacji internetowej jest po prostu złe. Odpowiedziałem, że może być źle w zależności od przechowywanych informacji, w przeciwnym razie dlaczego usługa sesji sieciowej powinna być nawet dostarczana przez Microsoft (mówiliśmy o ASP.NET).

Ponownie odpowiedział mi, że nawet w stwardnieniu rozsianym mogą z łatwością odpowiedzieć, że to zły projekt. I że może mi pokazać kilka oficjalnych dokumentów, które to pokazują.

Niestety nie mam już okazji skontaktować się z tym facetem, ale naprawdę chciałbym dowiedzieć się więcej o jego punkcie widzenia. Czy ktoś ma tutaj informacje / punkty widzenia na ten temat?

Nie sądzę, że miał na myśli tak „zły projekt”, jak „złą praktykę”. Ogólnie rzecz biorąc, aplikacja internetowa powinna być tak bezstanowa, jak to tylko możliwe. Chociaż na przykład może być konieczne podanie informacji o użytkowniku w celu autoryzacji przeglądania strony, informacje te mogą zostać zapisane na komputerze klienckim w postaci pliku cookie, a serwer po prostu sprawdza informacje o użytkowniku za każdym razem.

Byłoby to idealne, ale nie zawsze możesz liczyć na to, że klient będzie mógł zapisać pliki cookie. Ponadto polega na sprawdzeniu poprawności użytkownika w sposób bezstanowy, co potencjalnie wiąże się z pytaniem o informacje z bazy danych w celu uzyskania prostego żądania strony. Często łatwiej jest zapisać takie informacje w sesji.

Jednak po przekroczeniu Rubikonu wielu programistów ma ochotę zapisać nie tylko informacje uwierzytelniające w sesji, ale także wiele innych rzeczy. Jest to anty-wzorzec i powoduje, że twoja aplikacja internetowa jest silnie zależna od stanu, czego dokładnie należało unikać.

Niektórzy programiści uzależniliby się od technologii takiej jak Spring (jeśli używasz Javy), aby rozplątać bałagan zależności, ale argumentowałbym, że to tylko ułatwia tworzenie zależności, a nie ich eliminowanie. Takie technologie powinny pomóc Ci w rozwoju, a nie sprawić, że Twój wzór będzie mniejszym problemem.

Dlatego dobrą ogólną zasadą jest to, że jeśli możesz napisać go bezstanowego, prawdopodobnie lepiej to zrobić, inaczej ryzykujesz wpadnięcie w tę pułapkę. Oczywiście napotkasz sytuacje, w których jest to wymagane, ale ogólnie mówiąc, powinieneś zapisywać tylko te informacje, które w innym przypadku byłyby trudne do odzyskania.

Myślę, że mylisz dwa różne tematy: 1) sesje i 2) model strony formularzy internetowych asp.net

Sesja internetowa jest niezbędna do uwierzytelnienia użytkownika. Idealnie byłoby, gdyby sesja była używana tylko w tym celu. Nie należy przechowywać danych użytkownika w sesji (bez względu na to, czy znajdują się one na serwerze, w pliku cookie lub tak jak robi to asp.net/webforms: na samej stronie). Nikt nie powinien mówić, że sesja internetowa jest zła, ale raczej przechowuje dane użytkownikaw sesji jest złą praktyką. Przyczyny nieprzechowywania danych użytkownika na serwerze obejmują te same powody, aby uniknąć zmiennych globalnych. Przechowywanie danych użytkownika w plikach cookie lub na stronie może powodować problemy z bezpieczeństwem. Korzystanie z modelu strony asp.net również nie odpowiada bezpaństwowemu charakterowi sieci. Możesz przeprowadzić wyszukiwanie, aby dowiedzieć się więcej o tym, dlaczego formularze internetowe są złym projektem. Z drugiej strony sesje są niezbędną częścią aplikacji internetowych.

Kontrole i przechowywanie stanu sesji na stronie są w zasadzie włamaniem. Tak jest w przypadku MS - niezbędnego, ponieważ chcieli zapewnić środowisko programistyczne, w którym można projektować strony tak, jak to możliwe w środowisku WinForm.

MS same przeszły na architekturę MVC (najnowsza wersja - MVC 4), która jest raczej powrotem do tego, czym powinien być protokół - bezstanowy.

Są sytuacje, w których zapisywanie stanu jest nadal przydatne, ale należy rozumieć, że jest to wyjątek, a nie reguła.