Transcription

Dzień dobry, dzień dobry. Witam po przerwie świąteczno-sylwestrowej. Dzisiaj chciałbym Wam pokazać jak możecie zrobić system logowania w Gatsby. Gatsby jest to generator stron statycznych korzystający z Reacta, ale to, że jest to generator stron statycznych wcale nie oznacza, że nie możemy zrobić nic dynamicznego, więc dzisiaj pokażę Wam kilka rzeczy. Po pierwsze będzie nawiązanie do Strapi CMS. Jeżeli nie wiesz co to jest, to sprawdź sobie wcześniejsze materiały na tym kanale. W skrócie mówiąc jest to taki backend, dzięki któremu możemy łatwo dodawać treści i mamy na przykład takie funkcje jak możliwość logowania użytkownika i właśnie dzisiaj to użyjemy sobie w Gatsby. Teraz na kolejnej zakładeczce mamy Gatsby i w Gatsby napiszemy sobie dzisiaj ekran logowania. To jest właśnie mój blog fullstack.pl, do którego będę dodawał możliwość logowania właśnie z użyciem Gatsby i Strapi. I tutaj mamy formularzyk, który jak zobaczycie wpiszę sobie tutaj chmarusso, czyli mój e-mail, na który przychodzi spam i hasło, gdzie hasło jest bardzo proste. Klikamy logowanie i widzicie, że wewnątrz naszego Gatsby zalogowałem się na tą piękną stronę, która oczywiście jest na razie jeszcze w budowie, ale tutaj jak wejdziemy sobie w zakładkę Networks, to zobaczycie, że mamy tutaj wykonane zapytanie do lokalnie chodzącego Strapi, która jest jak widzicie na localhostie, na tam porcie 1337 i tutaj wysyłamy zapytanie typu post, w którym wysyłamy oczywiście nasz e-mail oraz nasze hasło. W odpowiedzi dostajemy encje użytkownika, gdzie mamy token, który umożliwia nam autoryzację czy autentykację zapytań do bazy danych, a w zasadzie do API, które później odpytuje bazę danych, więc to sobie zyskujemy i zapisujemy w lokal storydżu, więc jest tutaj zwrócona ta encja. Oczywiście możemy się wylogować i to mniej więcej dzisiaj pokażę Wam w dzisiejszym odcinku. Oczywiście kod znajdziecie na githubie, jeżeli macie jakieś pytania dotyczące dzisiejszego odcinka, jeżeli interesują Was jakieś dodatkowe rzeczy, to pytajcie w komentarzach, a ja postaram się w najbliższym czasie nagrać na ten temat materiał, więc nie przedłużam i teraz idziemy do kodu. Więc tak jak powiedziałem chwileczkę wcześniej, najpierw musimy stworzyć pewien rodzaj router w naszym Gatsby, ponieważ Gatsby działa tak, że w momencie gdy mamy na przykład folder pages i zrobimy sobie tam na przykład plik autor, no to wtedy automatycznie Gatsby generuje nam pod stronę autor i to jest jakby taki statyczny content, który jest po prostu serwowany automatycznie przez Gatsby. Natomiast my teraz chcemy zrobić strony dynamiczne, które pozwolą nam wyświetlać treści tylko i wyłącznie dla zalogowanych użytkowników. Zaczniemy może od stworzenia formularza, czyli tam będziemy chcieli logować naszego użytkownika i ten formularz też stworzymy w taki sposób nie w pełni statyczny, ale bardziej taki reactowy. Więc w tym celu sobie w folderze pages utworzymy nowy plik, który sobie nazwiemy app i oczywiście w tym pliku będziemy korzystać z reacta, więc trzeba sobie go zaimportować. Później będziemy potrzebować router. Router, z którego domyślnie korzysta Gatsby jest to rich router, który tak naprawdę mało różni się od react routera, ale myślę, że to jest w dzisiejszym odcinku akurat bardziej taki detal. No i oczywiście będziemy potrzebowali też layout, ponieważ moja strona może nie jest idealna, ale posiada layout, więc też zaimportujemy sobie tutaj layout, żeby oczywiście nasza podstrona logowania i inne podstrony, które będziemy dynamicznie generować w Gatsby, żeby one posiadały layout. Więc teraz zrobimy sobie po prostu consta, będziemy zwracać sobie komponent app i w nim oczywiście będzie to layout, a wewnątrz naszego layoutu będziemy mieli router i wewnątrz tego routeru będziemy mieli na przykład stronę login, którą chcemy wyświetlić na roucie app login. Oczywiście też muszę zaimportować sobie pod stronę login, a w zasadzie komponent, przepraszam, komponent app login, więc mamy tutaj na razie taki szablon, oczywiście musimy wyeksportować app z tego pliku, więc mamy layout, mamy router, mamy pierwszą stronę login, którą chcemy wyświetlić na podstronie app, zapiszemy, zobaczymy czy to działa, podpowiem Wam, że raczej nie. No i widzicie, że Gatsby jakoś tego co tutaj napisałem nie za bardzo ogarnia, więc trzeba mu pomóc i Gatsby ma różne takie pliki jak gatsby browser, gatsby config, gatsby ssr i gatsby node. Gatsby node, tutaj możemy wprowadzać różne jakby modyfikacje do procesu budowania naszego Gatsby i tutaj takim jednym z procesów, które możemy wprowadzić, jego odkomentuję, jest taki jakby hook on create page. Teraz w momencie, gdy ktoś wchodzi na podstronę app, to chcemy jakby dać znać Gatsbiemu, że to nie jest taka zwykła statyczna strona, jest to strona, która powinna zostać jakby obsłużona po stronie klienta, czyli z użyciem właśnie tego rich routera. Więc tutaj wykrywamy, że użytkownik wpisał ukośnik app i oczywiście w momencie, gdy wpisze ukośnik coś innego, na przykład login, to chcemy, żeby to było obsłużone po stronie klienta. Więc to jest pewna zmiana konfiguracyjna, którą musimy wprowadzić w Gatsby. Oczywiście wymaga to restartu serwera. Chwileczkę trzeba poczekać, zresetujemy serwer i zobaczymy, czy ta zmiana zadziałała. Oczywiście to znajdziecie w oficjalnej dokumentacji Gatsbiego, więc zachęcam, żebyście sobie doczytali, jak działa on create page. Ten fragment kodu oczywiście nie musicie go teraz spisywać z Waszego ekranu, możecie wejść sobie na GitHuba, do którego macie link pod tym nagraniem. No i teraz wracamy i widzicie, że już ta nasza strona logowania została wygenerowana. Ja oczywiście, żeby przyspieszyć nieco dzisiejsze nagrywanie, nie będę pisał wszystkiego całkiem od podstaw. Tutaj mam już przygotowany komponent login, który w zasadzie jeszcze nic nie robi, ale ma on tutaj po prostu pole e-mail, pole z hasłem, przycisk logowania. Tutaj są jeszcze możliwości logowania przez social media. Dzisiaj tego nie będę omawiał, ale jeżeli jest to dla Was interesujący temat, to dajcie znać w komentarzu, a to omówię. Teraz zobaczmy sobie, co tutaj słychać w kodzie. Więc jesteśmy w tym komponencie login. Mamy tutaj oczywiście możliwość wyświetlenia jakiegoś błędu, mamy refa do pola e-mail, mamy refa do pola password. Dzięki temu będziemy mogli łatwo sczytać sobie aktualną wartość, która znajduje się w tych polach po wpisaniu przez użytkownika. Tak, żebyśmy wiedzieli, jakie e-mail i jakie hasło chcemy wysłać do API. Więc teraz może napiszemy szybko tą funkcję, żeby zacząć się łączyć z API. Wcześniej zainstalowałem Axios. Axios wiem, że nie jest to może idealna biblioteka, ale ja osobiście ją lubię, bo łatwo pozwala mi ona pisać zapytania do API z użyciem async await. Oprócz tego też jest fajne konwertowanie jsonów od razu w Axios, więc ja akurat korzystam z Axios, ale jeżeli wolisz skorzystać z innej biblioteki, z natywnego fetcha, to korzystaj sobie do woli. W każdym razie mamy tutaj funkcję handle submit, która w momencie, gdy ktoś naciska ten przycisk, to po prostu jest ta funkcja wywoływana i teraz właśnie zrobimy sobie zapytanie do naszego API i zobaczymy, jak to wszystko działa. Więc oczywiście funkcja jest asynchroniczna, więc możemy sobie dowoli używać awaita. Ja to zrobię po prostu tak, że chcemy sobie wyciągnąć to, co nam zwraca Axios, czyli zmienna data i to się równa await i tutaj sobie napiszemy Axios post, ponieważ do Strapi chcemy wysłać zapytanie typu post i będziemy uderzać na adres localhost 1337, ukośnik auth, ukośnik local, a będziemy wysyłać tam następujące parametry, tak jakbyśmy wysyłali formularz, czyli identifier i to będzie email ref, current value. Używamy refa, ponieważ w tym polu mamy ref, email ref. Jeżeli nie wiesz, czym są refy, to odsyłam do oficjalnej dokumentacji Reacta albo u mnie na kanale też chyba gdzieś tam był filmik na ten temat, więc możecie to znaleźć. No i teraz tak samo zrobimy sobie z hasłem, więc password, ref, current i oczywiście też value, więc tutaj wysyłamy sobie te dane, dane wracają do zmiennej data i sobie możemy w konsol logu ładnie wylistować, żeby zobaczyć czy fragment tego kodu jako tako nam działa, więc odświeżymy sobie tą stronkę, wpiszemy sobie, zobaczymy zaraz co tutaj się dzieje w konsoli, wpisujemy chmaruso, hasło, no i widzicie, że z powrotem nam zwracane są dane z API. Jeżeli wpiszemy złe dane, to oczywiście wydarzy się coś tutaj złego, ponieważ w żaden sposób nie łapiemy błędów, więc naprawimy ten problem, wszystko wrzucimy sobie w blok try, oczywiście to musimy sobie nieco wciągnąć, tutaj zrobimy sobie catcha, oczywiście niezalecane jest łapanie wszystkich błędów, ale tutaj na cele edukacyjne myślę, że mi to wybaczycie, po prostu jeżeli jest wszystko ok, to chcemy zalogować użytkownika, jeżeli coś jest nie ok, nieważne czy serwer nie działa, czy e-mail jest zły, czy cokolwiek się złego wydarzyło, tu gdzieś zrobiliśmy babola, po prostu chcemy wyświetlić informację użytkownikowi i zrobimy to za pomocą ustawienia lokalnego state'u i ustawimy sobie state z użyciem funkcji set error i tutaj będzie po prostu set error błąd logowania. Dobra, wcześniej pisałem pojedynczo apostrofę, wiem, że niektórzy widzowie zwracają mi uwagę, że czasami jak coś tłumaczę, to nie trzymam się jakichś konwencji, ale to jest po prostu, jak się pisze i tłumaczy na raz, uwierzcie mi, nie jest to takie proste jak się wydaje. No i co, no i wracamy tutaj do tego naszego systemiku, no i już mamy złapany błąd. W momencie, gdy ktoś wpisze coś źle, to mamy po prostu błąd logowania, no ale jednak to nie jest wystarczające, bo mamy użytkownika, jakby wykonujemy zapytanie do API, dostajemy z powrotem token, ale nie zapisujemy tego nigdzie. No i to jest jakby dosyć ważna kwestia, żeby później móc wykonywać już zapytania, które będą zautoryzowane jako użytkownik, to oczywiście ten token musimy sobie gdzieś zapisać, więc za chwileczkę sobie go zapiszemy. Oczywiście na sposobów na zapisanie sesji jest kilka, jest session storage, jest local storage, możliwe jest też, jeżeli mamy odpowiednio skonfigurowany backend, zapisywanie sesji w ciasteczkach, więc są różne możliwości. Ja dzisiaj nie będę wchodził za bardzo w szczegóły tego, co jest lepsze, co jest gorsze, bo tutaj jakby nie chodzi o to w dzisiejszym odcinku, więc my sobie po prostu zrobimy jakąś tam funkcję, którą nazwiemy sobie set user i ta funkcja w momencie, gdy otrzyma po prostu informacje, które nam zwraca API, zostanie to zapisane w local storage. Nie chcę tutaj pisać rzeczy związanych z local storage w tym konkretnym komponencie, dlatego zaraz sobie napiszemy funkcję, taki helper, który będzie nam obsługiwał local storage, no i oczywiście jak użytkownik zostanie zapisany w local storage, no to chcemy też, jeżeli wcześniej ktoś wpisał np. błędnie jakieś informacje, to chcemy oczywiście wyzerować błędy, bo tym razem wszystko się powiodło i chcemy użytkownika przenawigować do pola, do kolejnej podstrony, którą będzie np. app account i oczywiście tą podstronę sobie zaraz zrobimy, a navigate jest to funkcja, która możemy zaimportować bezpośrednio z routera, no i co, no i możemy wziąć się za funkcję set user. Set user sobie zapiszemy w services, utworzyłem folder services, utworzyłem plik auth.js i sobie tutaj teraz napiszemy takie bardzo proste funkcje, więc na początek będzie export const, ponieważ oczywiście to będzie set user i set user będzie to funkcja, która przyjmuje użytkownika i go wrzuca do local storage, więc będzie window, local storage, set item i tutaj sobie item nazwiemy gatsby user i wrzucimy sobie tam wartość, oczywiście wartość, która nam zwraca API jest to json, pokażę Wam może szybko, jest to zwracane nam w formie jsona, więc oczywiście local storage tak fajnie nie działa, nie możemy przechowywać tam jsona, więc sobie go zamienimy po prostu na string, a w momencie gdy będziemy pobierać informacje użytkowniku z local storage to będziemy je decodować ze stringa do jsona, więc myślę, że to powinno nam zadziałać w ten sposób, czyli mamy po prostu set user, zrobimy sobie też get user, get user już nic nie przyjmuje, bo po prostu chcemy zczytać coś, co jest wewnątrz local storage i teraz zrobimy sobie window, local storage, get item i tu będzie gatsby user i jeżeli mamy element jakiś w local storage to oczywiście go zwracamy i parsujemy go, żeby mieć z powrotem json, czyli window, local storage, get item, gatsby user, a w sytuacji gdy nie mamy nic w local storage to chcemy po prostu zwrócić pusty obiekt. Tutaj returna nie wstawiłem, bo oczywiście jeżeli sobie zrobimy taki uproszczony zapis to po prostu get user automatycznie zostanie nam zwrócony. Tu jeszcze sobie zrobimy funkcyjkę, która jest dość często stosowana w momencie gdy robimy coś z server site renderingiem. Tutaj chodzi o to, że czasami fragment naszego kodu może zostać wykonany po stronie serwera i wtedy oczywiście zmienna window nie istnieje, więc kiedy chcemy sprawdzić, czy jest użytkownik to oczywiście chcemy być pewni, że ten fragment kodu jest wykonywany tylko w sytuacji, gdy jesteśmy po stronie klienta. Jeżeli nie rozumiesz tego co właśnie powiedziałem, czym jest server site rendering i klient site rendering to też na moim kanale znajdziesz materiał, w którym staram się to wszystko wyjaśnić. Więc mamy funkcję get user, z niej za chwileczkę będziemy sobie korzystać, bo chcemy przecież zabezpieczyć niektóre podstronne w taki sposób, żeby tylko użytkownik zalogowany mógł z nich skorzystać. Więc zapisujemy sobie to, wracamy sobie do naszej strony login, pobieramy sobie funkcję set user z tego helpera z tej strony, którą tutaj już sobie napisaliśmy i teraz już to powinno zadziałać, przynajmniej w taki sposób, że to co nam zwraca API zapisujemy sobie w local storage z użyciem tej funkcji set user. Za chwileczkę to przetestujemy, ale jeszcze będzie trzeba napisać tą podstronę, którą chcemy zabezpieczyć tak, żeby użytkownik mógł z niej skorzystać wyłącznie w sytuacji, gdy jest zalogowany. Więc przypomnijmy sobie co ja na razie zrobiłem. Na razie zrobiłem sobie tak naprawdę login. Login, tutaj jakby możemy być niezarejestrowani, niezalogowani, bo chcemy się w końcu zalogować, ale teraz zrobimy sobie podstronę, którą chcemy zabezpieczyć. I teraz jest oczywiście kilka sposobów, żeby to zrobić. Ja natomiast zrobię to w taki sposób, jak jest rekomendowane w dokumentacji Gatsby i w jakichś innych artykułach, które znajdują się w sieci. W każdym razie zrobimy sobie komponent, który nazwiemy sobie private root. On się znajduje w folderze app i ten private root będzie nam robił coś takiego, że będzie sprawdzał czy użytkownik jest zalogowany. Jeżeli jest zalogowany, jeżeli mamy w local storage użytkownika, to będziemy go wyświetlać, a jeżeli nie, to będziemy użytkownika wrzucać na ekran logowania. Więc oczywiście musimy mieć Reacta, więc sobie go zaciągniemy z Reacta. Później mamy funkcję navigate, ponieważ w sytuacji, gdy użytkownik nie jest zalogowany, to chcemy go wyrzucić. No i będziemy potrzebować jeszcze funkcję isLoggedIn z naszego serwisu auth. Oczywiście musimy to dopisać, bo jeszcze tego nie zrobiłem. W każdym razie jest to jeszcze niżej, serwis auth i funkcja isLoggedIn. Napiszemy sobie export const. Tak, jest to funkcja. I w momencie, gdy sobie sobie po prostu const user równa się get user, czyli pobieramy sobie użytkownika z local storage i zwracamy sobie po prostu taki warunek user.jvt i w momencie, gdy jest to fałsz, no to funkcja nam zwróci falsa. W momencie, gdy jvt znajduje się w tym local storage, w tym jsonie przeparsowanym, to oczywiście zwracamy true, więc jest to funkcja isLoggedIn, którą za chwileczkę sobie wykorzystamy. A wykorzystamy ją w taki sposób, że napiszemy sobie tutaj const private root i to jest oczywiście komponent, więc możemy sobie tutaj w ten sposób wyłuskać propsy. Props jednym z nich będzie komponent, który sobie zmienimy nazwę na komponent, ponieważ wewnątrz będziemy chcieli renderować daną podstronę, więc nazwiemy sobie ją komponent. Za chwileczkę zrozumiesz, co ja mam na myśli. No i sobie weźmiemy location i zrzucimy sobie tutaj resztę propsów, jeżeli ktoś by je oczywiście przekazał do komponentu private root. I teraz zrobimy coś takiego, jeżeli ktoś nie jest zalogowany i aktualna lokalizacja nie równa się ap.login, to wtedy co? To chcemy przerzucić gościa na stronę do logowania. Jeżeli ktoś jest niezalogowany, to chcemy go przerzucić, a jeżeli jest zalogowany, to chcemy zwrócić komponent, który przekazujemy jako props. Zaraz zobaczycie, kiedy go przekazujemy jako props, bo robimy to wewnątrz naszego komponentu ap. I tu po prostu, jeżeli ktoś by przekazał jakieś inne propsy, to też chcemy je podać niżej do tego komponentu. Tu jeszcze oczywiście nie chcemy nic renderować, chcemy po prostu gościa przerzucić i oczywiście zawsze jak zrobimy jakiś komponent, to musimy go wyeksportować z tego pliku, więc tutaj sobie zaimportujemy. private-root-components-app-private-root i tu oczywiście from. I teraz zobaczcie, jak chcemy coś zabezpieczyć, to będzie private-root-component, to będzie komponent jaki chcemy zabezpieczyć, to będzie komponent app-account i path jaki chcemy wykonać tutaj w tym naszym routerze to jest oczywiście app-account i teraz jeszcze zaimportujemy import-account from-components-app-account i komponent-account, szybko sobie napiszemy import-react-from-react i tutaj po prostu będziemy chcieli skorzystać sobie z tej naszej funkcji i wyświetlić sobie tego naszego użytkownika, więc będzie po prostu import-get-user-from i tutaj services-auth i tutaj zrobimy sobie export-default i od razu wyrzucimy sobie cons-gatsby-user równa się get-user, ponieważ chcemy go pobrać z local storage, a tutaj zwrócimy sobie jakiegoś tam diva i napiszemy witaj-gatsby-user-user-user-name, więc na razie zostawimy sobie to w ten sposób. Tutaj widzicie, że zaciągam sobie ten komponent i chcę go wyświetlić, private root ten komponent czuwa nad tym, żeby sprawdzić czy użytkownik jest zalogowany, jeżeli jest zalogowany to wyświetlamy komponent, który przekazujemy w propsie, przekazujemy w propsie account i oczywiście ma to działać na tej roocie, więc sprawdźmy czy to zadziała. App-account i widzicie, że jesteśmy przelogowani, znaczy przedirektowani. Tutaj jeszcze wprawne oko mogło zauważyć na tym filmiku problem, że jak mamy app-account to przekierowuje nas na login, ale nie wyświetla nam się ten formularz login. W momencie gdy odświeżymy to widzicie, że login jest. No i tutaj jest problem taki, że w momencie gdy mamy private root nie możemy tutaj skorzystać bezpośrednio z funkcji navigate tak jak mi tutaj podpowiedział Gatsby, znaczy VS Code, tylko musimy skorzystać z funkcji navigate, którą możemy sobie zaimportować z Gatsby i myślę, że też to poprawię w tym miejscu w naszym loginie. Zapiszemy i przetestujemy to teraz jeszcze raz i widzicie, że nasze logowanie już działa. Więc to wszystko co chciałem Ci dzisiaj pokazać w tym nieco przydługim filmiku, ale chciałem wszystko umówić krok po kroku. Jak widzicie Gatsby przede wszystkim pozwala Wam tworzyć dynamiczne strony z użyciem tak jak w zasadzie możecie to robić w React, możecie sobie przechowywać Waszego użytkownika w local storage, pobierać go. Oczywiście teraz musimy dopisać jeszcze jakieś hookie, które pozwolą nam na przykład za każdym razem odpytywać API i wysyłać w hederze zapisany token, tak żebyśmy mogli na przykład przydzielić użytkownikowi dostęp do danych zasobów, ponieważ pamiętajcie o tym, że to, że zabezpieczyliśmy na poziomie klienta, na poziomie Javascriptu, na poziomie Reacta dostęp do tej strony, to to jeszcze nic tak naprawdę nie zabezpiecza, ponieważ ktoś mógłby sobie w zakładce application dodać z palca coś tutaj do tego local storage i wtedy ta strona też by się takiemu hakerkowi ukazała. Więc teraz jest jeszcze ważne to, że w tym momencie jakbyśmy odpytywali serwer nasze API, nasz Strapi, nasz Headless CMS, cokolwiek, to musimy wysłać ponownie ten token, żeby faktycznie serwer wiedział, że my jesteśmy użytkownikami, którzy mogą mieć dostęp do danego zasobu. Więc to oczywiście, tego nam jeszcze brakuje. Jeżeli chcecie, to mogę nagrać materiał na ten temat, jeżeli nie, to macie zadanie domowe. Więc to wszystko z mojej strony. Dziękuję za obejrzenie tego filmiku. Jeżeli materiał był dla Ciebie pomocny, to możesz nagrodzić mnie lajkiem bądź komentarzem. Także dziękuję za uwagę. Trzymajcie się. Cześć.