Szeroka Perspektywa Full-Stack Web Developmentu: Session Cookie

0:00I teraz przechodzimy do ostatniego, według mnie bardzo istotnego, aczkolwiek często

0:04ignorowany sposobu uwierzytelnienia opartego o sesje oraz ciastka tzw.

0:09session kuki.

0:10W przypadku Nestle jest.

0:11Trzeba przyznać, że trzeba się trochę namęczyć, aby uzyskać taki mechanizm i

0:15szczerze mówiąc nie będziemy przez niego krok po kroku przechodzić.

0:19Jednocześnie warto jednak uwzględnić fakt,

0:21że w wielu przypadkach w momencie, gdy masz do czynienia z klasycznym front endem

0:25oraz backend, zdecydowanie dobrym pomysłem jest wykorzystanie session kuki.

0:29W tej sytuacji, analogicznie jak w

0:31przypadku tokenów, zasada jest bardzo podobna.

0:34Użytkownik loguje się loginem oraz hasłem za pomocą Big Crypt porównujemy hash

0:38zapisane w bazie danych i w momencie gdy się zgadzają oraz oczywiście gdy

0:42użytkownik istnieje, zwracamy Session Kuki, które jest ustawione przez serwer, a

0:46sama sesja zapisana właśnie na tym serwerze, a następnie przeglądarka dba o

0:51to, aby to Session Kuki trafiło z każdym kolejnym zapytaniem do naszego serwera.

0:55Zatem przejdźmy teraz do kodu.

0:57Uruchomimy aplikację, włączmy serwer, no i

1:00przechodzimy do sprawdzenia co tutaj dokładnie przygotowałem.

1:03Mianowicie podobnie jak w poprzednim przypadku mamy tutaj end pointy

1:07umożliwiające zarejestrowanie konta, zalogowanie, dostęp do zabezpieczonej

1:11ścieżki oraz w tym przypadku możliwość wylogowania.

1:15Co ciekawe, zaimplementowanie mechanizmu

1:17wylogowania nie jest wcale takie oczywiste w przypadku tokenów jw.

1:21W każdym razie jeżeli chodzi o możliwość rejestracji użytkownika, jest ona tak

1:25naprawdę bliźniacza jak do tej, którą omawialiśmy przy okazji tokenów od WT.

1:29Po prostu użytkownik przesyła login oraz hasło, a następnie odbieramy te dane,

1:33szyfruje hasło i wrzucamy je do naszej bazy.

1:36Z powrotem przesyłamy informacje na temat użytkownika.

1:39W tym przypadku jednak, już pomijając

1:41informacje na temat samego hasła, pamiętaj proszę o tym, aby zwracać uwagę, aby nie

1:46przesyłać takich informacji z powrotem do klienta.

1:49Proponuję więc, abyśmy spróbowali

1:51zalogować się wykorzystując metodę Signal i przekazując tutaj dane użytkownika.

1:57W tym przypadku wykorzystam tutaj tylko

1:58nazwę Oferent 1 i mamy tutaj informację o tym, że konto zostało utworzone.

2:04Następnie możemy wykorzystać ten login

2:06oraz hasło do tego, aby zalogować się do naszego konta.

2:10W momencie gdy to zrobimy zwróć uwagę, że mamy tutaj stosowną odpowiedź, ale

2:14dodatkowo pojawiło się tutaj również ciasteczko.

2:17Ciasteczko to zawiera informacje na temat

2:19sesji i tym samym też w momencie, gdy będziemy próbowali dostać się do ścieżki

2:23dostępnej tylko dla zalogowanych użytkowników, to w związku z tym, że mamy

2:28to ciastko, otrzymamy tutaj poprawną odpowiedź.

2:30Co więcej, ta odpowiedź powiązana jest bezpośrednio z zalogowanym użytkownikiem.

2:34Oczywiście w przypadku zapytania GET po prostu zignoruj to co mamy.

2:38Tutaj nie przesyłamy żadnego ciała zapytania.

2:41W każdym razie wszystko się tutaj zgadza.

2:42W związku z tym możemy wylogować się, no i ciasteczko zostanie w tym momencie

2:47zniszczone, podobnie jak sesja i tym samym też, gdy będziemy próbowali uzyskać dostęp

2:52do chronionego zasobu, tym razem otrzymamy status 403.

2:56Wszystko się tutaj zgadza, mechanizm

2:58działa, a my jedyne co musimy zrobić, to zastosować local strategii, który

3:02wykorzystujemy właśnie na etapie logowania użytkownika, czyli dokładnie tutaj, ale

3:07już w momencie, gdy mamy endpoint, który chcemy chronić naszą sesją, no to

3:11wykorzystujemy authentication, który zapisany jest dokładnie w tym miejscu.

3:16Zwróć uwagę, że w tym miejscu już nie wykorzystujemy password.

3:19Czy jest tylko konkretnie metody dostępne w paczce Express Sessions?

3:23W związku z tym, jak widzisz nawet nie

3:25mamy tutaj zbytnio powiązania z tym czy jest, tylko wykorzystujemy pakiet dla

3:29Express, gdzie jest do tego, aby obsługiwać sobie sesję.

3:32Na koniec dnia jeszcze to, co nas będzie tutaj interesowało to to, aby w naszym

3:36głównym pliku aplikacji skonfigurować sobie odpowiednio to rozszerzenie.

3:40I tutaj, podobnie jak w przypadku tokenów

3:42WT, wykorzystujemy Secret Token, które możesz wygenerować analogicznie jak

3:47wcześniej poleceniem, które wyświetla się w tym momencie w mojej konsoli.

3:51Zatem myślę, że na tym etapie sam

3:53mechanizm jest dla Ciebie jasny, ponieważ tak naprawdę po jego konfiguracji, która

3:57dzieje się tutaj, tak naprawdę jedyne co musisz zrobić, to utworzyć sobie bardzo

4:01prosty graf, a następnie podłączać go do swoich end pointów.

4:05Cała reszta dzieje się dla Ciebie

4:06automatycznie, no bo w momencie gdy użytkownik zaloguje się do swojego konta i

4:10tylko musimy aktywować ponownie serwer, no to jego ciastko zostanie utworzone i tym

4:15samym też nie musimy w żaden sposób przekazywać go z kolejnymi zapytaniami ze

4:19względu na to, że o to dba już nasza przeglądarka, a jednocześnie też serwer.

4:24A z kolei serwer dba o to, aby weryfikować

4:27te sesje, a w momencie gdy sesja wygaśnie np.

4:29po stronie serwera lub też np.

4:31w momencie gdy serwer zostanie w tym przypadku wyłączony oraz włączony

4:35ponownie, to nie będziemy mieć dostępu do naszego zasobu.

4:39Wynika to z faktu, że sesje w tym

4:41przypadku przechowywane są w pamięci serwera, a co za tym idzie w momencie jego

4:45restartu wszystkie te informacje są tracone.

4:47Oczywiście nic nie stoi na przeszkodzie, aby przechowywać sesje np.

4:51w plikach bądź w bazie danych.

4:53Aczkolwiek znowu tutaj chodzi tylko o to, aby było dla Ciebie jasne, że istnieje

4:57możliwość przechowywania sesji w sposób bardziej.

5:00A już to, czy faktycznie z takiego sposobu

5:02skorzystasz zależy tylko od Ciebie oraz Twoich potrzeb.

5:05Jeżeli chodzi o uwierzytelnianie za pomocą sesji, to by było na tyle.

5:09W związku z tym dziękuję za uwagę i do usłyszenia w kolejnych materiałach.