Jak zachować aplikacje bezstanowe

To może być skomplikowane pytanie, ale staram się lepiej zrozumieć bezpaństwowość.

Na podstawie tego, co przeczytałem, aplikacje internetowe powinny być bezstanowe, co oznacza, że ​​każde żądanie jest traktowane jako niezależna transakcja. W związku z tym należy unikać sesji i plików cookie (ponieważ oba są stanowe). Lepszym rozwiązaniem jest użycie Tokenów, które są bezstanowe, ponieważ nic nie jest przechowywane na serwerze.

Próbuję więc zrozumieć, w jaki sposób aplikacje internetowe mogą być bezstanowe, gdy przechowywane są dane z mojej sesji (takie jak przedmioty w koszyku)? Czy faktycznie są one gdzieś przechowywane w bazie danych, a następnie okresowo są czyszczone? Jak to działa, gdy używasz tokena zamiast plików cookie?

A następnie jako powiązane pytanie, czy główne strony internetowe (Amazon, Google, Facebook, Twitter itp.) Są w rzeczywistości bezpaństwowcami? Czy używają tokenów lub plików cookie (lub obu)?

„aplikacje internetowe powinny być bezstanowe” należy rozumieć jako „aplikacje internetowe powinny być bezpaństwowe, chyba że istnieje bardzo dobry powód, aby mieć stan” . „Wózek na zakupy” jest z założenia stanową funkcją, a zaprzeczanie, że przynosi efekt przeciwny do zamierzonego. Chodzi przede wszystkim o zachowanie stanu aplikacji między żądaniami.

Alternatywą, którą mogłem sobie wyobrazić jako bezpaństwową stronę internetową, która implementuje koszyk, byłaby aplikacja jednostronicowa, która utrzymuje koszyk całkowicie po stronie klienta, pobiera informacje o produktach za pomocą wywołań AJAX, a następnie wysyła je do serwera naraz użytkownik dokonuje kasy. Wątpię jednak, czy kiedykolwiek widziałem, aby ktoś to zrobił, ponieważ nie pozwala on na korzystanie z wielu kart przeglądarki i nie zachowuje stanu po przypadkowym zamknięciu karty. Jasne, istnieją obejścia takie jak używanie localstorage, ale potem znowu masz stan, tylko na kliencie zamiast na serwerze.

Ilekroć masz aplikację internetową, która wymaga utrwalania danych między odsłonami, zwykle robisz to, wprowadzając sesje. Sesję, do której należy żądanie, można zidentyfikować za pomocą pliku cookie lub parametru adresu URL dodanego do każdego linku. Pliki cookie powinny być preferowane, ponieważ utrzymują Twoje adresy URL pod ręką i zapobiegają przypadkowemu udostępnieniu adresu URL z identyfikatorem sesji. Jednak posiadanie tokenów URL jako rezerwowych jest również niezbędne dla użytkowników, którzy dezaktywują pliki cookie. Większość platform programistycznych ma system obsługi sesji, który może to zrobić natychmiast po wyjęciu z pudełka.

Po stronie serwera informacje o sesji są zwykle przechowywane w bazie danych. Buforowanie w pamięci po stronie serwera jest opcjonalne. Może znacznie skrócić czas reakcji, ale nie pozwoli na przesyłanie sesji między różnymi serwerami. Będziesz więc potrzebował trwałej bazy danych jako rezerwowej.

czy główne strony internetowe (Amazon, Google, Facebook, Twitter itp.) są w rzeczywistości bezpaństwowcami? Czy używają tokenów lub plików cookie (lub obu)?

Czy pozwalają ci się zalogować? Po zamknięciu karty i ponownym odwiedzeniu witryny nadal jesteś zalogowany? Jeśli tak, używają plików cookie, aby zachować Twoją tożsamość między sesjami.

To prawda, że ​​aplikacje internetowe powinny być bezstanowe. Jednak zmienne sesji, pliki cookie i tokeny nie naruszają tego, gdy wszystkie są przechowywane na kliencie (przeglądarce internetowej). Mogą to być parametry w żądaniu.

Oto uproszczony model:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

Może to działać w przypadku wymiany stosu inżynierii oprogramowania . Ta odpowiedź, którą wpisuję, jest częścią stanu mojej przeglądarki internetowej. Dopóki jest to jedyne miejsce, w którym się znajduje, nie jest dostępne dla nikogo oprócz mnie. Ale jak tylko uderzę, Post your Answermoja przeglądarka wysyła ją do serwera internetowego. Serwer WWW przetwarza pocztę bez własnego stanu. Dowie się, kim jestem z mojej przeglądarki i bazy danych. Po sprawdzeniu i dodaniu go do bazy danych serwer internetowy szybko o mnie zapomina.

To właśnie oznacza bezpaństwowiec. Serwer nie ponosi odpowiedzialności za zapamiętywanie tych informacji. To nie jest jego praca.

Takie postępowanie ma wiele zalet. Jeśli serwer WWW ma wyciek pamięci, jest wykrywalny, ponieważ jego pojemność pamięci nie powinna rosnąć. Jeśli serwer WWW ulegnie awarii, moja tożsamość się z nim nie zgadza. Jeśli ktoś próbuje przeprowadzić atak typu „odmowa usługi”, nie może użyć do tego celu zasobów stanu serwera WWW, ponieważ serwer internetowy nie przydziela mu żadnego stanu między sesjami. Wszystko to ma na celu zapewnienie stabilności serwera WWW. W ten sposób, gdy zacznie działać, będzie działać.

Teraz, na pewno, zużywam zasoby w bazie danych, ale te zasoby zostały najpierw sprawdzone pod kątem mojej rezerwy przez coś stabilnego, na którym możemy liczyć, aby chronić bazę danych przed dziką i zwodniczą siecią: bezpaństwowy serwer sieciowy wymuszający reguły biznesowe.

aplikacje internetowe powinny być bezstanowe

Nonsens. Żądania sieciowe powinny być bezstanowe. Mówiąc dokładniej, żądania internetowe są bezstanowe.

Ale stwierdzenie, że cała aplikacja powinna być bezpaństwowcem, jest kompletnym nonsensem.

każde żądanie jest traktowane jako niezależna transakcja.

Tak, dokładnie . Lub dokładniej, tak, koniecznie . Przez HTTP każde żądanie jest z natury niezależne od wszystkich innych żądań. Dodanie „stanowości” do HTTP wymaga jawnej identyfikacji, przechowywania i pobierania „stanu” dla każdego żądania „stanowego”. A to wymaga wysiłku, zmniejsza wydajność i dodaje złożoności.

I z tych powodów każde żądanie, które może być bezpaństwowe „powinno” być bezpaństwowe.

W związku z tym należy unikać sesji i plików cookie (ponieważ oba są stanowe). Lepszym rozwiązaniem jest użycie żetonów

Kilka rzeczy: Tokeny można również powiązać z pamięcią sesji. Pliki cookie nie muszą być powiązane z przechowywaniem sesji. Tokeny są często przechowywane w plikach cookie. A czasami sesja jest po prostu odpowiednim narzędziem do pracy.

Oznacza to, że przynajmniej czasami , sesje i ciasteczka są po prostu jako „lepszy”, jak tokeny!

[Tokeny] są bezstanowe, ponieważ nic nie jest przechowywane na serwerze.

Cóż, to wszystko. Na tym właśnie polega dogmat „bezpaństwowości”. Chociaż, żeby być jasnym, nie chodzi o przechowywanie „niczego” na serwerze, nie chodzi o przechowywanie stanu sesji na serwerze.

Na przykład moja skrzynka odbiorcza Gmaila jest w stanie. I cholernie lepiej jest przechowywać na serwerze! Ale to nie jest stan sesji .

Więc zamiast serwerów, które mogą wziąć mały identyfikator i dowiedzieć się, kim jesteś itd., Bezpaństwowe aplikacje chcą przypomnieć, kim jesteś i co robisz z każdą cholerną prośbą. Stan aplikacji nadal istnieje, klient jest po prostu odpowiedzialny za jego utrzymanie.

Teraz, jeśli ten stan jest niewielki, to prawdopodobnie jest OK. W niektórych przypadkach jest to bardzo dobre.

A potem oczywiście są rzeczy, których po prostu oczekujemy, że będą stanowcze ...

w jaki sposób aplikacje internetowe mogą być bezstanowe, gdy przechowywane są dane z mojej sesji (takie jak przedmioty w koszyku)? Czy faktycznie są one gdzieś przechowywane w bazie danych, a następnie okresowo są czyszczone?

Dwie opcje. Albo masz sesję, albo odmawiasz!

... ale poważnie. Zwykle nie przechowujesz koszyka w pliku cookie. Coś w rodzaju koszyka na zakupy albo będzie przechowywane w „tradycyjnej” sesji, albo będzie przechowywane jako Cartobiekt, z jakimś identyfikatorem, którego serwer użyje do wciągnięcia go do kolejnych żądań. Coś w stylu ... uch ... sesji ...

Naprawdę na poważnie: w dużym stopniu „stanowość” jest tym, co nazywamy, gdy dwóch komunikujących się agentów może kontekstualizować wiadomości w rozmowie. Sesja, tradycyjnie rozumiana, jest właśnie tym, co zwykle nazywamy mechanizmem, za pomocą którego się to dzieje.

Twierdzę, że niezależnie od tego, czy korzystasz z tokenów, czy „sesji” dla każdego żądania obsługiwanego przez serwer, musisz kontekstualizować to żądanie, aby je spełnić, albo nie. Jeśli kontekst nie jest konieczny, nie pobieraj go. Jeśli kontekst jest konieczny, lepiej go mieć w pobliżu!

A następnie jako powiązane pytanie, czy główne strony internetowe (Amazon, Google, Facebook, Twitter itp.) Są w rzeczywistości bezpaństwowcami? Czy używają tokenów lub plików cookie (lub obu)?

Prawdopodobnie jedno i drugie. Ale ogólnie rzecz biorąc, robią dokładnie to, co robisz: ustawiają pliki cookie, aby identyfikować rekordy „stanowe” w ogromnych bazach danych „sesyjnych”.

O ile to możliwe, podejrzewam, że wprowadzili podstawowe roszczenia dotyczące tożsamości w krótkotrwałe „tokeny”, aby uniknąć niepotrzebnej rywalizacji o scentralizowane przechowywanie. Ale fakt, że wiele z tych usług pozwala mi „wylogować się ze wszystkich innych lokalizacji”, jest dobrym wskaźnikiem, że jeśli w ogóle korzystają z tokenów, są przynajmniej „obsługiwane” przez pół-tradycyjny model sesji .

Stanowość niekoniecznie jest złą rzeczą, ale musisz zrozumieć różnicę między aplikacjami stanowymi a bezpaństwowymi. Krótko mówiąc, aplikacje stanowe przechowują informacje o bieżącej sesji, a aplikacje bezstanowe nie. Informacje przechowywane na stałe jako część konta użytkownika mogą, ale nie muszą być przechowywane w sesji, ale przechowywanie informacji związanych z kontem użytkownika samo w sobie nie powoduje stanu aplikacji. Stan wymaga, aby serwer przechowywał informacje o sesji bieżącego użytkownika poza tym, co utrzymuje przeglądarka klienta. Na przykład klient może się uwierzytelnić i otrzymać plik cookie JSESSIONID, który następnie wysyła do serwera przy każdym żądaniu. Jeśli serwer zacznie przechowywać rzeczy w zakresie sesji aplikacji na podstawie tego JSESSIONID, staje się stanowy.

Bezpaństwowość

Przez „bezstanowy” rozumiemy, że serwer i klient nie przechowują bieżących informacji o sesji użytkownika. Klient i serwer mogą używać jakiejś formy tokena, aby zapewnić uwierzytelnianie między żądaniami, ale nie są przechowywane żadne inne bieżące informacje. Typowym przykładem użycia takiego rozwiązania może być serwis informacyjny, w którym większość użytkowników (nowych konsumentów) konsumuje informacje, ale nie generuje informacji, które wracają do witryny. W takich przypadkach witryna nie musi utrzymywać żadnych informacji o bieżącej sesji użytkownika. Należy pamiętać, że witryna może nadal używać plików cookie do identyfikowania użytkownika i przechowywania informacji o korzystaniu z niego przez tego użytkownika, ale może to nadal być uważane za bezpaństwowe, ponieważ wszystko zarejestrowane może być transakcyjne, np. Jaki link kliknął użytkownik, który może zostać zarejestrowany przez serwer, ale nie utrzymywany w sesji użytkownika.

Stan na serwerze

Na serwerze aplikacja stanowa zapisuje informacje o stanie o bieżących użytkownikach. Podejście to ogólnie polega na wykorzystaniu plików cookie do identyfikacji systemu użytkownika, dzięki czemu można zachować stan na serwerze między żądaniami. Sesje mogą być uwierzytelniane lub nie, w zależności od kontekstu aplikacji. Zaletą stanowych aplikacji serwerowych jest buforowanie informacji o stanie użytkownika na serwerze, przyspieszenie wyszukiwania i czas odpowiedzi strony. Z drugiej strony przechowywanie informacji w zakresie sesji jest kosztowne, a na dużą skalę staje się bardzo zasobochłonne. Tworzy również potencjalny wektor ataku dla hakerów, którzy próbują przejąć identyfikatory sesji i ukraść sesje użytkownika. Wyzwaniem dla stanowych aplikacji serwerowych jest ochrona sesji użytkowników przed nieoczekiwanymi przerwami w świadczeniu usług, np. Awarią serwera.

Stan klienta

Korzystając z JavaScript i nowoczesnych technologii przeglądarki, takich jak sessionStorage, aplikacja może teraz łatwo przechowywać informacje o stanie sesji użytkownika na urządzeniu tego użytkownika. Ogólnie aplikacja może być nadal uważana za stanową, ale zadanie utrzymania stanu zostało przeniesione do klienta. Takie podejście ma dużą zaletę (dla osoby zarządzającej aplikacją internetową) nad utrzymywaniem stanu na serwerze, ponieważ w rzeczywistości każdy użytkownik utrzymuje własny stan i nie ma obciążenia infrastruktury serwera. W skali sieci tego rodzaju wybór architektury ma ogromny wpływ na koszty sprzętu i energii elektrycznej. Utrzymanie stanu na serwerze może dosłownie kosztować miliony dolarów rocznie. Przejście do systemu utrzymującego stan na kliencie może wówczas zaoszczędzić miliony dolarów rocznie.

Tokeny v. Ciasteczka

Pliki cookie działają jako identyfikatory urządzeń / przeglądarek klienta. Mogą być używane do przechowywania wszelkiego rodzaju rzeczy, ale ogólnie przechowują jakąś formę identyfikatora, np. CFID / CFTOKEN w aplikacjach CFML. Pliki cookie można ustawić tak, aby długo działały w przeglądarce użytkownika, umożliwiając między innymi utrzymanie uwierzytelnienia w aplikacji między sesjami przeglądarki. Pliki cookie można również ustawić tylko na pamięć, więc wygasają, gdy użytkownik zamknie przeglądarkę.

Tokeny to generalnie pewne informacje identyfikujące użytkownika, które są generowane na serwerze (za pomocą szyfrowania w celu szyfrowania informacji), przekazywane do klienta i zwracane na serwer z kolejnym żądaniem. Mogą być one przekazywane w nagłówku żądania i odpowiedzi, co jest częstym wzorcem w aplikacjach jednostronicowych. Idealnie byłoby, gdyby każde żądanie / odpowiedź generowało nowy token, więc token nie może zostać przechwycony i wykorzystany później przez atakującego.

Aplikacje pojedynczej strony i stan klienta

W przypadku SPA informacje o stanie są ładowane do przeglądarki klienta i tam przechowywane. Kiedy stan się zmienia, np. Gdy opublikujesz aktualizację na swoim koncie w mediach społecznościowych, klient przekazuje tę nową transakcję do serwera. W takim przypadku serwer zapisuje tę aktualizację w trwałym magazynie danych, takim jak baza danych, i przekazuje klientowi wszelkie informacje potrzebne do synchronizacji z serwerem na podstawie aktualizacji (np. Identyfikator aktualizacji).

Zauważ, że ten wzorzec przechowywania stanu na kliencie oferuje korzyści dla doświadczeń online / offline, ponieważ możesz być odłączony od serwera, wciąż mając nieco użyteczną aplikację. Twitter jest dobrym przykładem tego przypadku, w którym możesz przejrzeć wszystko załadowane po stronie klienta w swoim kanale Twitter, nawet jeśli nie masz połączenia z aplikacją serwera Twitter. Ten wzorzec powoduje również złożoność synchronizacji między serwerem a klientem, co stanowi całość. Złożoność rozwiązania jest kompromisem za możliwość utrzymania stanu na kliencie.

Stan na kliencie sprawia, że ​​aplikacje internetowe są bardziej podobne do tradycyjnych aplikacji komputerowych. W przeciwieństwie do aplikacji komputerowych, zazwyczaj nie wszystkie informacje o koncie są ładowane do sesji klienta w przeglądarce. Takie postępowanie w wielu przypadkach byłoby niepraktyczne i powodowałoby złe doświadczenia. Czy możesz sobie wyobrazić próbę załadowania całego pola Gmaila do przeglądarki? Zamiast tego klient przechowuje informacje, takie jak etykieta / folder, na który patrzysz i gdzie na liście wiadomości e-mail w tym folderze, którego szukasz. Równoważenie informacji o stanie, które należy zachować, i tego, o co należy poprosić w razie potrzeby, jest kolejnym wyzwaniem inżynieryjnym tego rodzaju, i znowu stanowi kompromis między praktycznością a zapewnieniem dobrych wrażeń użytkownika.

Wózki sklepowe i tym podobne

Jeśli chodzi o szczegóły, takie jak koszyki, to naprawdę zależy od rozwiązania. Koszyk na zakupy może być przechowywany w bazie danych na serwerze, może być przechowywany tylko w zakresie sesji na serwerze, a nawet może być przechowywany na kliencie. Amazon ma trwałe koszyki na zakupy dla zalogowanych użytkowników i „tymczasowe” wózki dla anonimowych użytkowników, chociaż koszyki te są do pewnego stopnia trwałe.

Gdy mówisz o czymś takim jak Google, który jest naprawdę zbiorem różnych aplikacji pod tą samą marką, prawdopodobnie nie mają one wspólnej architektury, a każda z nich jest zbudowana w sposób, który najlepiej odpowiada potrzebom jej użytkowników. Jeśli chcesz dowiedzieć się, jak zbudowana jest witryna, otwórz narzędzia programistyczne w przeglądarce i spójrz na nią. Sprawdź pliki cookie, obserwuj ruch sieciowy i zobacz, jak działa.

Przepraszam, jeśli ta odpowiedź trochę się wtrąca, ale stanowość jest złożonym tematem.

Sesji i plików cookie nie trzeba unikać. Nadal możesz je mieć za pomocą bezstanowych aplikacji internetowych.

Istnieje duża różnica między Javą a Ruby on Rails. Aplikacje Java będą przechowywać sesję w pamięci za pomocą klucza sesji zapisanego w pliku cookie. Jest to szybki sposób na odzyskanie stanu użytkownika i koszyka. Jednak zawsze musisz trafić na ten sam serwer podczas sesji.

Aplikacje Railsowe przechowują identyfikator użytkownika w podpisanym, zaszyfrowanym pliku cookie. Nie można go manipulować. Podczas ładowania strony aplikacja internetowa pobiera stan, użytkownika i koszyk z bazy danych. Jest to wolniejsze, ale kluczem jest to, że możesz trafić w każdą instancję ! Umożliwia to ponowne uruchamianie, skalowanie i zamykanie instancji do woli. Bardzo wygodne Można to również przyspieszyć dzięki współużytkowanej pamięci podręcznej, takiej jak Redis. Możesz też przechowywać koszyk w pliku cookie, pod warunkiem, że jest wystarczająco mały.

Dzięki sprytnym technikom możesz osiągnąć bezpaństwowość i dowolnie skalować.

Protokół jest bezstanowy.

Ale z tego niekoniecznie wynika, że ​​aplikacje korzystające z protokołu powinny być bezstanowe.

Oto kilka powiązanych odpowiedzi StackOverflow, które dobrze wyjaśniają różnicę:

• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34678600#34678600
• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34677668#34677668

Odnosząc się do bezstanowych - np. W usłudze RESTful HTTP - ma zamiar uniknąć przechowywania stanu po stronie serwera. W najlepszym wypadku obejmuje to również unikanie przechowywania dowolnego stanu w bazie danych lub innych trwałych magazynach w wewnętrznej bazie danych. Aby to wyjaśnić, mówię o stanie, a nie o danych w ogóle. Wygląda na to, że niektórzy mieszają rzeczy.

Bezpaństwowa komunikacja ma kilka zalet, zwłaszcza jeśli chodzi o skalowalność i dostępność.

Lepszym rozwiązaniem jest użycie Tokenów, które są bezstanowe, ponieważ nic nie jest przechowywane na serwerze.

To prawda (w przypadku niektórych protokołów uwierzytelniania i autoryzacji). Tokeny mogą (ale nie same w sobie) zawierać wszystkie informacje w żądaniu, które są potrzebne do uwierzytelnienia użytkownika lub autoryzacji działania. Na przykład spójrz na JWT .

Próbuję więc zrozumieć, w jaki sposób aplikacje internetowe mogą być bezstanowe, gdy przechowywane są dane z mojej sesji (takie jak przedmioty w koszyku)? Czy faktycznie są one gdzieś przechowywane w bazie danych, a następnie okresowo są czyszczone? Jak to działa, gdy używasz tokena zamiast plików cookie?

Jeśli chodzi o przykład koszyka. Przechowywanie wszystkich produktów w koszyku po stronie klienta nie stanowi problemu bez użycia sesji lub plików cookie. Możesz znaleźć przykład na smashingmagazine.com . Ale możliwe jest również zrealizowanie bezpaństwowego koszyka z ciasteczkami (przynajmniej jeśli twój asortyment nie jest tak duży i wystarcza Ci miejsce na 4kb).

Nie zrozum mnie źle, to nie znaczy, że powinieneś wdrożyć koszyk bezstanowy za każdą cenę. Amazon lub inne duże platformy zakupów online używają stanowych implementacji koszyków, ponieważ wygoda użytkownika i użyteczność są dla nich ważniejsze niż dopasowanie technicznych niefunkcjonalnych wymagań, takich jak skalowalność.

Zasadniczo tokeny nie są używane do przechowywania informacji, takich jak przedmioty w koszyku. Służą do bezpaństwowego uwierzytelniania i autoryzacji.

A następnie jako powiązane pytanie, czy główne strony internetowe (Amazon, Google, Facebook, Twitter itp.) Są w rzeczywistości bezpaństwowcami? Czy używają tokenów lub plików cookie (lub obu)?

Jeśli pytasz, czy używają plików cookie lub tokenów do uwierzytelnienia, odpowiedzią jest, że używają obu. W przypadku użytkowników najczęściej wykorzystywane są pliki cookie dla klientów technicznych, w większości używane są tokeny.

OK, cytowana reguła jest technicznie niepoprawna. Wszystkie warstwy aplikacji internetowej mają stan.

Reguła ma na celu „nie utrzymuj serwera stanów na sesję po stronie”.

Tzn. Zmienne sesji w ASP , które były powszechnie używane do robienia rzeczy takich jak elementy w koszyku / nazwie użytkownika itp.

Powodem jest to, że zabraknie pamięci na serwerze, gdy aplikacja zyska więcej użytkowników. Przeniesienie magazynu do bazy danych lub współdzielonej pamięci podręcznej nie rozwiązuje problemu, ponieważ nadal występuje wąskie gardło.

Aby utrzymać stan aplikacji dla poszczególnych użytkowników bez dotykania tego problemu, przenieś stan na stronę klienta. Na przykład umieść elementy koszyka w pliku cookie lub bardziej zaawansowanym magazynie po stronie klienta.

Ponieważ liczba klientów skaluje się wraz z liczbą użytkowników, cała aplikacja nie będzie miała wąskiego gardła i będzie dobrze skalowana.