Co to są sesje? Jak oni pracują?


332

Właśnie zaczynam się uczyć programowania aplikacji internetowych, używając Pythona. Spotykam terminy „ciasteczka” i „sesje”. Rozumiem, że pliki cookie przechowują niektóre informacje w parze klucz-wartość w przeglądarce. Ale mam trochę zamieszania co do sesji, również w sesji przechowujemy dane w pliku cookie w przeglądarce użytkownika.

Na przykład - loguję się przy użyciu username='rasmus'i password='default'. W takim przypadku dane zostaną opublikowane na serwerze, który ma mnie sprawdzić i zalogować, jeśli zostanie uwierzytelniony. Jednak podczas całego procesu serwer generuje również identyfikator sesji, który będzie przechowywany w pliku cookie w mojej przeglądarce. Teraz serwer przechowuje również ten identyfikator sesji w swoim systemie plików lub magazynie danych.

Ale na podstawie samego identyfikatora sesji, w jaki sposób mógłby poznać moją nazwę użytkownika podczas mojego kolejnego przejścia przez stronę? Czy przechowywanie danych na serwerze jako dict gdzie kluczem byłaby identyfikator sesji i szczegółów jak username, emailitd być wartości?

Czuję się tutaj dość zmieszany. Potrzebuję pomocy.


9
„Czy przechowuje dane na serwerze jako dykt, gdzie kluczem będzie identyfikator sesji, a wartości takie jak nazwa użytkownika, adres e-mail itp. Są wartościami?” ...tak. „Dict” może być relacyjną bazą danych, ale w zasadzie tak to działa.
bobince

14
Chciałem też zrozumieć sesje internetowe, teraz rozumiem. Skończyłem pisać własną wiki, jeśli to pomogło: Machinesaredigging.com/2013/10/29/how-does-a-web-session-work
Eloone

Jeśli nie wiesz: przechowywanie hasła po stronie klienta nie jest bezpieczne, nawet jeśli hasło jest zaszyfrowane (w rzeczywistości nie robi to różnicy. Krakers może bezpośrednio wprowadzić zaszyfrowane hasło, tworząc fałszywe ciasteczko) są lepszymi sposobami przechowywania statusu logowania.
cytsunny

1
Napisałem własne, używając szczegółów poziomu protokołu - bitspedia.com/2012/05/…
Asif Shahzad

Odpowiedzi:


400

Ponieważ HTTP jest bezstanowy, w celu powiązania żądania z dowolnym innym żądaniem potrzebny jest sposób przechowywania danych użytkownika między żądaniami HTTP.

Pliki cookie lub parametry adresu URL (np. Http://example.com/myPage?asd=lol&boo=no ) są odpowiednimi sposobami przesyłania danych między 2 lub więcej żądaniami. Nie są one jednak dobre, jeśli nie chcesz, aby te dane były czytelne / edytowalne po stronie klienta.

Rozwiązaniem jest przechowywanie tej strony serwera danych, nadawanie jej „id” i informowanie klienta (i przekazywanie z powrotem przy każdym żądaniu http) tego identyfikatora. Proszę bardzo, sesje wdrożone. Możesz też użyć klienta jako wygodnego zdalnego magazynu, ale szyfrowałbyś dane i utrzymywałeś tajny serwer.

Oczywiście należy wziąć pod uwagę inne aspekty, na przykład nie chcesz, aby ludzie przejmowali sesje innych, chcesz, aby sesje nie trwały wiecznie, ale wygasały i tak dalej.

W konkretnym przykładzie identyfikator użytkownika (może to być nazwa użytkownika lub inny unikalny identyfikator w bazie danych użytkownika) jest przechowywany w danych sesji po stronie serwera po udanej identyfikacji. Następnie dla każdego żądania HTTP otrzymanego od klienta identyfikator sesji (podany przez klienta) wskaże Ci prawidłowe dane sesji (przechowywane przez serwer), które zawierają uwierzytelniony identyfikator użytkownika - w ten sposób Twój kod będzie wiedział, jakiego użytkownika to rozmawia z.


3
„nie chcesz, aby te dane były utrzymywane po stronie klienta”. Dlaczego nie? Jeśli zastosujesz silną kryptografię, możesz pozwolić klientowi zachować dane sesji zaszyfrowane i zapisane w pliku cookie. To znacznie upraszcza skalowanie do wielu węzłów, ponieważ serwery nie muszą niczego „zapamiętywać”.
Matt Harrison

5
@MattHarrison, jak odszyfrujesz dane bez „zapamiętywania” po stronie serwera? W każdym razie próbowałem rozwinąć ten temat w swojej odpowiedzi.
Luke404

2
@MattHarrison pamiętaj, że przechowywanie dużej ilości danych po stronie użytkownika zwiększy ruch.
nitsas

5
Czy strona trzecia nie byłaby w stanie działać jako użytkownik, gdyby mogła przechwycić klucz sesji użytkownika? Zakładając, że strona nie korzysta z HTTPS, wygląda na to, że osoba trzecia może maskować się jako użytkownik kluczem sesji, nawet jeśli klucz jest zaszyfrowany. Serwer po prostu go odszyfruje.
user137717,

2
@ user137717 tak, jest to możliwe, jeśli zezwolisz na dostęp do sesji dosłownie „każdemu, kto prezentuje poprawny identyfikator sesji”. Istnieje wiele ograniczeń, które możesz wprowadzić, jednym z najłatwiejszych i najczęstszych jest przechowywanie adresu IP klienta w sesji: jeśli klient z innego adresu IP ma ten sam identyfikator sesji, oznacz go jako sfałszowany i usuń sesję.
Luke404,

110

Proste objaśnienie przez analogię

Wyobraź sobie, że jesteś w banku i próbujesz uzyskać pieniądze ze swojego konta. Ale jest ciemno; brzeg jest zupełnie czarny: nie ma światła i nie widać dłoni przed twarzą. Jesteś otoczony przez kolejne 20 osób. Wszystkie wyglądają tak samo. I każdy ma ten sam głos. I każdy jest potencjalnym złym facetem. Innymi słowy, HTTP jest bezstanowy.

Ten bank jest zabawnym rodzajem banku - dla argumentu oto, jak działają rzeczy:

  1. czekasz w kolejce (lub on-line) i rozmawiasz z kasjerem: składasz prośbę o wypłatę pieniędzy, a następnie
  2. musisz chwilę poczekać na kanapie, a 20 minut później
  3. musisz iść i odebrać pieniądze od bankomatu.

Ale w jaki sposób narrator odróżni cię od wszystkich innych?

Pamiętaj, że bankomat nie może cię zobaczyć ani rozpoznać, ponieważ wszystkie światła są zgaszone. Co się stanie, jeśli kasjer wyda 10 000 USD na wypłatę innej osobie - niewłaściwej osobie ?! Jest absolutnie niezbędne, aby kasjer mógł rozpoznać cię jako osobę, która dokonała wypłaty, abyś mógł otrzymać pieniądze (lub zasoby), o które prosiłeś.

Rozwiązanie:

Kiedy po raz pierwszy pojawiasz się w kasjerze, on lub ona mówi ci coś w tajemnicy:

„Kiedykolwiek do mnie mówisz”, mówi narrator, „najpierw powinieneś zidentyfikować się jako GNASHEU329 - w ten sposób wiem, że to ty”.

Nikt inny nie zna tajnego hasła.

Przykład sposobu, w jaki wypłaciłem gotówkę:

Postanawiam więc iść i odpocząć przez 20 minut, a potem idę do kasjera i mówię: „Chciałbym odebrać moją wypłatę”

Kasjer pyta mnie: „kim jesteś?”

„To ja, panie George Banks!”

"Udowodnij to!"

A potem podaję moje hasło: GNASHEU329

„Na pewno panie Banks!”

Zasadniczo tak działa sesja. Umożliwia jednoznaczną identyfikację na morzu milionów ludzi. Musisz identyfikować się za każdym razem, gdy masz do czynienia z kasjerem.

Jeśli masz jakieś pytania lub są niejasne - napisz komentarz, a ja postaram się wyjaśnić.

Objaśnienie za pomocą zdjęć:

Sesje wyjaśnione za pomocą obrazu


9
Uwielbiam to wyjaśnienie - w twojej analogii, w jaki sposób miałbyś zapobiec podsłuchiwaniu przez innych użytkowników, a także usłyszeć tajny kod dostępu, który mówi ci narrator? Innymi słowy, jeśli identyfikator_sesji zostanie skradziony, czy nie byłoby możliwe naśladowanie twoich danych uwierzytelniających?
wmock

Przejęcie sesji @wmock to z pewnością problem: sprawdź to! owasp.org/index.php/Session_hijacking_attack
BKSpurgeon

2
piękny przykład !! powinny być udostępniane chętnym umysłom, które chcą się uczyć!
Victor

w twojej analogii GNASHEU329jest hasło użytkownika, które generuje token uwierzytelnienia, który wygasa do określonego czasu; Pan Banks może następnie użyć tokena uwierzytelnienia, aby dokonać kilku kolejnych wypłat bez konieczności wielokrotnego podawania kasjera swojego hasła?
Daniel Lizik

@DanielLizik jesteś def. zrozumienie koncepcji! Ale nie mam wystarczającej wiedzy na temat przepływów pracy opartych na tokenach, aby udzielić inteligentnej odpowiedzi. Ogólna zasada jest taka, że ​​serwer musi być w stanie w jakiś sposób zidentyfikować osobę, która wysyła żądanie.
BKSpurgeon

39

„Sesja” to termin odnoszący się do czasu przeglądania strony przez użytkownika. Ma reprezentować czas od pierwszego przybycia do strony w witrynie do czasu, kiedy przestaną korzystać z witryny. W praktyce nie wiadomo, kiedy użytkownik skończy z witryną. Na większości serwerów występuje limit czasu, który automatycznie kończy sesję, chyba że ten sam użytkownik zażąda innej strony.

Gdy użytkownik po raz pierwszy połączy jakiś identyfikator sesji, zostanie utworzony (sposób wykonania zależy od oprogramowania serwera WWW i rodzaju uwierzytelnienia / logowania, którego używasz na stronie). Podobnie jak pliki cookie, zwykle nie jest to już wysyłane w adresie URL, ponieważ jest to problem bezpieczeństwa. Zamiast tego jest przechowywany wraz z wieloma innymi rzeczami, które łącznie są również nazywane sesjami. Zmienne sesji są jak pliki cookie - są to pary nazwa-wartość wysyłane wraz z żądaniem strony i zwracane wraz ze stroną z serwera - ale ich nazwy są zdefiniowane w standardzie internetowym.

Niektóre zmienne sesji są przekazywane jako nagłówki HTTP . Są one przekazywane tam iz powrotem za kulisy przeglądania każdej strony, więc nie pojawiają się w przeglądarce i nie mówią wszystkim, co może być prywatne. Wśród nich są: USER_AGENT lub typ przeglądarki żądającej strony, REFERRER lub strona, która łączy się z żądaną stroną itp. Niektóre oprogramowanie serwera WWW dodaje własne nagłówki lub przenosi dodatkowe dane sesji specyficzne dla oprogramowania serwera. Ale standardowe są dość dobrze udokumentowane.

Mam nadzieję, że to pomaga.


Wiem, że na serwerach IIS, których używam, mogę uzyskać nazwę użytkownika z nagłówka USER_NAME, ale może to być charakterystyczne dla IIS.
Tim Rourke,

Co oznacza tutaj REFERRER?
Gab 是 好人

@Gab 是 FER REFERRER zwykle oznacza dowolny ciąg, który klient wysyła w nagłówku żądania HTTP „Referer”. To powinno zawierać adres URL zasobu, że wiesz, o którym mowa klienta do bieżącego zasobu.
Luke404,

Dzięki, powinno , więc niekoniecznie. więc myślę, że ludzie często używają tego nagłówka z inną semantyką niż sugerowana w RFC, prawda?
Gab 是 好人

Najpierw napisałeś, Like cookies, this usually doesn't get sent in the URL anymorea potem Session variables are like cookies - they're name-value pairs sent along with a request for a page. Co się dokładnie dzieje? Czy jest wysyłany przy następnym żądaniu?
KPMG

19

HTTP jest bezstanowym protokołem połączeń, co oznacza, że ​​serwer nie może rozróżniać różnych połączeń różnych użytkowników.

Stąd przychodzi ciasteczko, gdy klient po raz pierwszy łączy się z serwerem, serwer generuje nowy identyfikator sesji, który później zostanie wysłany do klienta jako wartość ciasteczka. I od tej pory ten identyfikator sesji identyfikuje to połączenie klienta, ponieważ w ramach każdego żądania HTTP zobaczy odpowiedni identyfikator sesji w plikach cookie.

Teraz dla każdego identyfikatora sesji serwer zachowuje pewną strukturę danych, która umożliwia mu przechowywanie danych specyficznych dla użytkownika. Tę strukturę danych możesz abstrakcyjnie wywołać sesją.


1
Czy możesz rzucić na to nieco więcej światła - „Teraz dla każdego identyfikatora sesji serwer zachowuje pewną strukturę danych, która pozwala mu przechowywać dane specyficzne dla użytkownika, tę strukturę danych możesz abstrakcyjnie wywołać sesją.”? Jakie konkretne informacje o kliencie przechowuje serwer?
realPK

Czy możesz rzucić na to nieco więcej światła - „Teraz dla każdego identyfikatora sesji serwer zachowuje pewną strukturę danych, która pozwala mu przechowywać dane specyficzne dla użytkownika, tę strukturę danych możesz abstrakcyjnie wywołać sesją.”? Jakie konkretne informacje o kliencie przechowuje serwer?
Gab 是 好人

To samo pytanie, co powyżej, pomocne byłoby udzielenie odpowiedzi.
Suraj Jain,

4

Pomyśl o HTTP jako o osobie (A), która ma UTRATĘ PAMIĘCI KRÓTKOTERMINOWEJ i zapomina o każdej osobie, gdy tylko zniknie ona z pola widzenia.

Teraz, aby zapamiętać różne osoby, A robi zdjęcie tej osobie i zachowuje ją. Zdjęcie każdej osoby ma numer identyfikacyjny. Gdy ta osoba ponownie pojawi się w polu widzenia, ta osoba podaje A swój numer identyfikacyjny, a A znajduje swoje zdjęcie według numeru identyfikacyjnego. I voila !!, A wie, kto jest tą osobą.

To samo dotyczy HTTP. Cierpi na UTRATĘ PAMIĘCI KRÓTKOTERMINOWEJ. Wykorzystuje Sesje do rejestrowania wszystkiego, co zrobiłeś podczas korzystania ze strony internetowej, a następnie, kiedy wrócisz, identyfikuje cię za pomocą plików cookie (Cookie jest jak token). Zdjęcie to Sesja tutaj, a ID to Cookie tutaj.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.