Czy localStorage traktuje się jako sesje w aplikacji?

0

Nie wiem czego używasz na backendzie, ale właśnie chodzi o to, żeby nic specjalnego nie robić. Jeśli masz jakiś framework backendowy, to on sam sobie poradzi z logowaniem itd.

Tak mi się wydaje, że taki trend się pojawia, bo np. Laravel teraz namawia do tego, żeby się nie bawić w tokeny, jeśli nasze API ma być używane tylko do naszej jednej SPA. Ma to sens.

Pamiętaj, że cookie są zawsze wysyłane przez przeglądarkę do określonej domeny, więc Ty od strony klienta nic nie musisz robić.

0

Te ciastka byłyby ustawiane przez serwer jako identyfikator sesji i serwer na podstawie tego identyfikatora wyszukiwałby gdzieś w pamięci danych użytkownika do którego ten id sesji należy. Tutaj to już stricte zależy od backendu - przeważnie sam mechanizm logowania masz dostępny z pudełka, trochę konfiguracji (wskazanie np. bazy danych, url pod który trzeba uderzyć itd). Po zalogowaniu, serwer zwraca Ci headera (Set-Cookie) na podstawie którego zostanie stworzone ciasteczko z ID sesji (najbezpieczniej: HttpOnly + Secured). Potem to cookie z każdym requestem będzie wysyłane do serwera. .

Cookie nie służy tylko do identyfikowania sesji, może służyć też do przechowywania danych, tylko cookies są wysyłane z każdym requestem do serwera.

0

To już teraz mam w ogóle mętlik w głowie. Skoro framework backendowy sam sobie poradzi z logowaniem to mam tylko stworzyć cookies po stronie klienta? Czy my na pewno mówimy o cookiesach javascriptowych?

Czy np. takie OAuth2 w firebase to właśnie session persistent?

0

Najlepiej jak poczytasz dokładnie jak działają ciastka. Ciastko to ciastko - klient (JavaScript) może je odczytać, ale serwer też je automatycznie dostaje, bo przeglądarka wysyła nagłówek Cookies. Wyjątkiem są ciastka HttpOnly, których ze względów bezpieczeństwa przeglądarka "nie chce widzieć", więc nie odczytasz ich JavaScriptem. Ciebie by interesowało oczywiście zwykłe ciastko, a nie HttpOnly.

Załóżmy, że masz formularz logowania w SPA. Wysyłasz login i hasło do API. Jeśli są poprawne, w sesji zapisywana jest informacja, że jesteś zalogowany jako taki i taki użytkownik. Jeśli nie chcesz żadnych przekierowań, musisz jakoś poinformować stronę klienta, że logowanie się powiodło, żeby odświeżyć widok. Ale ciastko od teraz już po prostu działa samo - każde wywołanie API ma dostęp do tego ciastka, bo przeglądarka, ilekroć robisz request do tej domeny, dokleja nagłówek Cookie. JavaScript też wie o tym ciastku, ale akurat po stronie klienta niewiele Ci to ciastko powie. Przy każdym "prawdziwym" wejściu na stronę możesz wysyłać zapytanie do API czy ktoś jest zalogowany, czy nie. Ja bym nie nie robił z ciastkami po stronie klienta w takiej implementacji.

0

@bearek: a możesz powiedzieć czy OAuth2 w firebase z wykorzystanie localStorage to właśnie session persistent?

0

Nigdy nie używałem firebase. W OAuth2 bym się nie bawił, bo to służy raczej do udostępniania tożsamości użytkowników innym aplikacjom. Niektórzy używają tego protokołu wewnątrz pojedynczej aplikacji, ale to jest trochę bez sensu.

0

Załóżmy, że masz formularz logowania w SPA. Wysyłasz login i hasło do API. Jeśli są poprawne, w sesji zapisywana jest informacja, że jesteś zalogowany jako taki i taki użytkownik.

@bearek a co tutaj miałeś na myśli po przez sesje? Informacja jest zapisywana w sesji, ale jak to konkretnie i gdzie jest zapisywane?

0

Nie znałem pojęcia session persistent ale jak teraz czytam co to jest, to nie jest to session persistent. Oauth2 służy Ci tylko jako serwer autoryzacyjny, natomiast session persistent służy do tego, że gdy serwer przechowa sobie jakieś dane lokalnie (np w pamięci w celu optymalizacji) to w przypadku gdy system będzie miał kilka instancji serwerów, będziesz uderzał do tej samej instancji. session persistent to nie to samo co sesja.

0

Poczytaj najlepiej czym jest sesja. Są różne sposoby implementacji sesji, np. w PHP domyślnie tworzone są pliki na serwerze, w których zapisane są wartości zmiennych sesyjnych.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0