Czy localStorage traktuje się jako sesje w aplikacji?

0

Czy localStorage traktuje się jako sesje w aplikacji?

0

Nie rozumiem chyba pytania?

A jesli jednak rozumiem no to localstorage sie nie kasuje po ~20 minutach tylko jest trwaly.

3

Nie. localStorage i sessionStorage nie są równoznaczne z sesją. Jednakże sessionStorage możesz wykorzystać do przechowywania danych które mają być zapisane dla danej sesji (localStorage w przeciwieństwie do sessionStorage zapisuje dane do czasu aż użytkownik w jakiś sposób sam ich z niego noe usunie).

3

Nie. Storage to tylko miejsce w przeglądarce po to aby zapisywać jakieś dane. Session/local itp. Różnią się głównie tym jak długo dane są zapisywane. Natomiast sesja to cały mechanizm przesyłania danych między serwerem a klientem.

1

Tak jak kolega phanc mówi. Sesja to jest cały mechanizm, na który składa się ciastko z ID sesji plus mechanizm przechowywania danych sesji.

Mnie to pytanie zadane przez kolegę konewkę85 nie dziwi, bo kiedyś sam nie do końca rozróżniałem te pojęcia. Teoretycznie możesz użyć localStorage (lub sessionStorage) do przechowywania identyfikatora sesji. Ale już same wartości powinny się pojawić tam, gdzie nie możesz ich samodzielnie zmieniać. Weź pod uwagę, że np. w sesji może znaleźć się ID zalogowanego użytkownika. Trzeba pamiętać o tym, że dane sessionStorage i localStorage można dowolnie modyfikować.

Pamiętam jak jako dzieciak przechowywałem w sesji login i hasło, bo nie rozumiałem jak to działa :)

0

W takim razie w jaki sposób można użyć sesji w aplikacji typu SPA np. w React.js? Musi być zwracany jakiś token z serwera? Bo ruzmiem, że cookie w takim wypadku też nie będzie sesją?

0

Jeśli twoja SPA ma mieć swoje API, które nie jest potrzebne nigdzie indziej, wtedy nie bawiłbym się w żadne tokeny, tylko normalnie działał z ciastkami. Wydaje mi się, że teraz coraz częściej pojawia się takie rozwiązanie, zamiast przerostu formy nad treścią w postaci używania tokenów za wszelką cenę.

Ale jeśli chcesz koniecznie kompletnie uniezależnić swoje API od ciastek, masz do wyboru kilka rozwiązań, np. JWT.

0

@bearek: cookies też może użytkownik sam usunąc. Jednak cookies już są traktowane jako sesja? API mi nie jest potrzebne.

0

A co jest złego w usunięciu ciastka? Powiem Ci więcej - użytkownik może nawet edytować cookie bez problemu. Kiedyś były do tego dodatki do przeglądarek, dziś zrobisz to w web toolsach. Ale to w niczym ine przeszkadza.

Cookies nie są "traktowane jako sesja". Przeczytaj jeszcze raz to, co pisaliśmy wyżej.

0

@bearek: wcześniej pisałeś, że nie bawiłbyś się w żadne tokeny, tylko byś użył ciasteczek, ale chyba do konca nie rozumiem co miałeś na myśli. Co z tymi ciasteczkami by miało się dziać żeby były traktowane jako sesja?

Czy np. chodzi o to, żeby uderzać do api np. do konkretnego id usera np.?

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