MVP aplikacji w rekordowym czasie z Bubble: Logowanie z Google
Logika
17 godz. 49 min · Biznes i Automatyzacje
Krzysiek PiekarzAutomation Specialist / No-code DeveloperCzego się nauczysz
- Pracy z edytorem Bubble na bardziej zaawansowanym poziomie
- Tego jak wyszukiwać, filtrować i edytować rekordy z bazy danych wbudowanej w Bubble
- Czym są privacy rules - czyli jak zabezpieczyć dostęp do naszych danych przed nieuprawnionym dostępem
- Praktycznej pracy z frontend i backend workflows
- Dodatkowo wdrożymy do naszej aplikacji system płatności Stripe oraz powiadomienia mailowe z wykorzystaniem np. SendGrid i innych
- Pokażę Ci jak łączyć się z zewnętrznymi API poprzez dostępny w Bubble plugin API Connector
- A także jak rozszerzyć funkcjonalność naszej aplikacji poprzez proste automatyzacje z serwisem Make
- Na koniec zajmiemy się również podpięciem naszej customowej domeny oraz publikacją aplikacji
Czy w Twojej głowie pojawił się pomysł na aplikację, która zrewolucjonizuje świat na miarę Facebook'a, Instagrama albo Airbnb? A może zgłosił się do Ciebie klient, który chce przetestować i wdrożyć swój projekt w jak najszybszym czasie?Jeśli tak było to na pewno zadajesz sobie teraz kolejne pytanie - od czego zacząć? Czy muszę posiadać odpowiednią wiedzę programistyczną? Na jaki język programowania się zdecydować lub z jakiego gotowego framework'u skorzystać? A może zatrudnić profesjonalnego designera i software house, który pozwoli mi zrealizować ten projekt?Niezależnie od tego czy czy zdecydujesz się działać sam/a, czy też przekażesz projekt do zewnętrznej agencji i tak staniesz przed kolejnym dylematem jakim jest nauka programowania lub konieczność przepalenia nawet setek tysięcy złoty na coś, co może okazać się niewypałem.Na szczęście szybki rozwój narzędzi no-code sprawia, że możesz wybrać jeszcze trzecie wyjście. Zaprojektować, zbudować i wypuścić w świat swoją wymarzoną aplikację tylko za pomocą własnych sił i to bez konieczności posiadania specjalistycznej wiedzy programistycznej, a nawet posiadając jedynie podstawową znajomość narzędzi do design'u.Pamiętaj również o tym, że projekt ten podzieliłem na dwie części. Ten kurs to druga część, w której zapoznamy się z bardziej zaawansowanymi opcjami, jakie zapewnia nam edytor Bubble. Zdobytą w ten sposób wiedzę teoretyczną wykorzystamy od razu w praktyce dodając do naszego statycznego designu odpowiednią logikę, dzięki czemu nasz finalny projekt będzie już w pełni działającą aplikacją.Jeśli tylko potrafisz w podstawowym zakresie pracować z edytorem Bubble, budować w nim design aplikacji i rozumiesz czym są option sets oraz workflows to posiadanie wiedzy z poprzedniego kursu nie jest koniecznie wymagane. Natomiast szczerze zachęcam Cię przynajmniej do przejrzenia materiałów z pierwszej części, gdzie skupiamy się właśnie na podstawach, ponieważ teraz będziemy efektywnie przechodzić do bardziej zaawansowanych tematów i rozbudowywać naszą aplikację.
Czego nauczysz się w ramach tego Kursu?
W tym kursie „MVP aplikacji w rekordowym czasie z Bubble (Logika)” nauczę Cię jak zamienić statyczny layout na pełnoprawną aplikację. Poruszymy takie tematy jak praca z bazą danych, privacy rules oraz bardziej zaawansowane workflows, które dodamy zarówno na froncie jak i backendzie naszej aplikacji. Dzięki zdobytej wiedzy dodamy logikę wszędzie tam, gdzie tego wymaga nasz projekt, a dodatkowo wzbogacimy go o możliwość płatności poprzez najbardziej popularny na świecie system jakim jest Stripe. To jednak nie koniec ponieważ przygotowałem dla Ciebie również szereg innych ważnych zagadnień, które omówimy i wykorzystamy w praktyce.W ramach nauki skupimy się na jak najbardziej praktycznym podejściu. Zapomnij o długich i nudnych lekcjach pełnych teorii, które zapomnisz zaraz po obejrzeniu. Będziemy budować a nie debatować! W ten sposób nauczysz się pracować z edytorem Bubble na poziomie zaawansowanym. Zrozumiesz jak zabezpieczyć swoje dane przed nieuprawnionym dostępem, w jaki sposób pobierać i dynamicznie filtrować rekordy z bazy danych. A także jak wykorzystać auto-binding by móc je aktualizować bez wykorzystania skomplikowanych workflows.Dodamy do naszej aplikacji prosty komunikator, który pozwoli na wymianę wiadomości pomiędzy użytkownikami. Zadbamy również o możliwość wysyłania powiadomień mailowych poprzez zewnętrzne serwisy by ich wygląd był zgodny z naszym brandem. Nie zabraknie również takich tematów jak SSO z Google czy też proste automatyzacje z wykorzystaniem serwisu Make.
Dla kogo jest ten kurs?
Materiał szkoleniowy został zaprojektowany tak, aby mogło z niego skorzystać jak najszersze grono odbiorców. Nieważne czy jesteś totalnym laikiem, czy też posiadasz już wiedzę z zakresu programowania lub designu, na pewno znajdziesz tu coś dla siebie. A więc kto jeszcze może skorzystać z wiedzy zawartej w tym kursie?
O ile w poprzedniej lekcji ułatwiliśmy sobie nieco zadanie korzystania z
zewnętrznych API poprzez wykorzystanie make.
com, tak w tej lekcji wracamy już do edytora, gdzie będziemy pracować zarówno z
Backend Workflow AWS, jak i API konektorem.
Długo zastanawiałem się czy dołączyć tą lekcję do kursu, ale uznałem, że będzie to
całkiem niezłe wprowadzenie do bardziej zaawansowanych tematów, jakie przyjdzie
nam przerabiać, gdy będziemy integrować się ze Stripe.
Natomiast zdaję sobie sprawę z faktu, że teraz wkraczamy już na
bardziej zaawansowane rejony.
Jeśli w trakcie tej lekcji najdzie Cię myśl, że teraz to już przesadziłem i nic z
tego nie rozumiesz, więc może warto sobie odpuścić całe to bubble to moja rada jest
następująca wyjdź na długi spacer lub jeśli wolisz usiąść w fotelu z ulubionym
drinkiem, oczywiście bezalkoholowym i po prostu odpocznij od tego wszystkiego.
W ten sposób zbierzesz sobie mentalne siły, by siąść do tematu kolejnego dnia.
Niestety nauka nowych API i rozeznanie się w tym, jak łączyć się z różnymi systemami
będzie od teraz częścią Twojej codziennej pracy.
Jeśli jednak postanowisz kontynuować przygodę z narzędziami no code.
Dlatego też, jeśli nie uda się za pierwszym podejściem, to
warto spróbować jeszcze raz.
Pamiętaj, że ja też byłem kiedyś dokładnie w tym samym miejscu co Ty i stawałem
przed tymi samymi problemami.
A skoro mi się udało, to wierzę, że i Ty dasz radę.
Ale wróćmy do tematu samej lekcji.
Chciałbym poruszyć dwa sposoby na to, w jaki sposób możemy dodać do naszej
aplikacji opcję rejestracji i logowania użytkowników za pomocą serwisu Google.
I tu jedna bardzo ważna uwaga.
W lekcji skupimy się tylko i wyłącznie na tym, by umożliwić naszym użytkownikom
logowanie się do serwisu i nic więcej.
Nie będziemy ustawiać opcji wykonywania żadnych działań w ich imieniu, np.
Dostępu do ich kalendarza itd.
Jest to bowiem już znacznie bardziej złożony proces, który wymaga regularnego
odświeżania tokenu dla takiego usera oraz dodatkowo dostęp do tak
zwanych zakresów wrażliwych.
A Google za taki uznaje właśnie między innymi kalendarz.
Wymaga bardziej wnikliwej analizy Twojej aplikacji przez samo Google.
W momencie, gdy będziesz chciał opublikować swój serwis i przestać
korzystać z kont testowych.
Natomiast sposób, a w zasadzie dwa sposoby, które Ci pokażę, pozwolą Ci w
prosty sposób utworzyć konto w Twoim serwisie właśnie za pomocą Google.
Ale dlaczego właściwie chciałbyś dodawać taką opcję?
Otóż odpowiedź jest bardzo prosta bezpieczeństwo i wygoda.
Jeśli będziesz korzystać z zewnętrznych serwisów, takich jak na przykład Google,
to niejako przerzucasz odpowiedzialność właśnie na ich barki, bo to one muszą
zadbać o to, by poprawnie zweryfikować, czy użytkownik, który się loguje
jest tym, za kogo się podaje.
Jeden z moich klientów postawił ostatnio warunek, że chce, by dostęp do serwisu
odbywał się wyłącznie za pomocą Microsoft i kont na Azure.
Więc nie pozostało mi nic innego jak wdrożyć odpowiednie rozwiązanie.
Kolejnym plusem jest fakt, że nie musisz martwić się o to, by wdrażać do serwisu
obsługę błędów przy logowaniu i rejestracji.
My tego nie robiliśmy do tej pory, ponieważ bywa to dość czasochłonnym
procesem i zwyczajnie zabrakło na to miejsca w kursie, który już i tak
jest wypchany po brzegi materiałem.
A skoro nie obsługujemy błędów, to nie musimy się też martwić opcjami
przypomnienia i resetowania hasła.
Co prawda Babel posiada do tego odpowiednie mechanizmy i strony, ale to na
Twoich barkach jako dewelopera spoczywa obowiązek ich poprawnego wdrożenia.
Mógłbyś teraz zapytać, czemu w takim razie powinniśmy w ogóle korzystać z obsługi
użytkowników przez samo Babel, a nie zaimplementować wyłącznie innych serwisów?
Tu chyba najlepszą odpowiedzią jest to, że nigdy nie wiesz, kto może zostać
Twoim kolejnym użytkownikiem.
To, że ja posiadam konto w serwisie Google nie oznacza od razu, że
wszyscy dookoła też tak mają.
Zawsze trafi się użytkownik, który go nie posiada, podobnie jak kont w innych
serwisach typu Facebook, Microsoft i tak dalej.
Ale chcę z kolei zarejestrować się właśnie u Ciebie i nie możesz mu
takiej opcji zablokować.
Dodatkowo, jeśli zaimplementujesz opcję z zewnętrznym serwisem, użytkownik nie
będzie mógł zmienić maila, z jakiego korzysta w naszej aplikacji.
Wynika to właśnie z tego, że to nie my odpowiadamy za autoryzacje,
tylko właśnie serwis zewnętrzny.
A skoro to krótkie wprowadzenie mamy już za sobą, to przystąpmy do właściwego
działania w obu przypadkach, które sobie obsłużymy.
Punkt startowy jest identyczny, czyli rozpoczynamy od zalogowania się do
naszej konsoli developerskiej w Google.
Jeśli wygenerowałeś już klucze do obsługi mapki w Babel, link do tego jak to zrobisz
znajdziesz w video nr 13 w pierwszym module.
To pierwszy krok masz już za sobą, bo to oznacza, że utworzyłeś swój pierwszy
projekt w konsoli i podpięłeś system płatności.
A jeśli tego jeszcze nie zrobiłeś, to oczywiście zachęcam Cię, abyś to
zrobił właśnie w tym momencie.
Czyli zapauzuj to wideo i utwórz właśnie ten projekt i wygeneruj te
klucze, o których mówię.
Dlatego też teraz logujemy się do naszego projektu i przystępujemy do dalszych prac.
A więc przechodzę sobie tutaj, do swojej konsoli w Google'a.
Mam, jak widzisz tutaj ten swój projekt oraz klucze, które wygenerowałem
właśnie do obsługi map.
I teraz naszym zadaniem w pierwszej kolejności będzie utworzenie
tutaj ekranu zgody OAuth.
Jest to ten ekran, który widzisz na samym początku, kiedy właśnie logujesz się
poprzez swoje konto Gmaila czy też Google Workspace do jakiegoś serwisu.
A więc klikamy tutaj.
I kolejno dodajemy tutaj nowy ekran zgody.
Ja już to utworzyłem, a więc mogę sobie kliknąć Edit app i już Ci
mówię co musisz wybrać.
Przede wszystkim będzie to konto typu external i tam masz internal i external, a
więc wybierz to drugie konto typu external.
I teraz powinieneś trafić właśnie tutaj na ten pierwszy krok.
Nazwa aplikacji to w moim przypadku z USA.
Ty możesz oczywiście wpisać dowolną nazwę.
Ten e-mail pojawi Ci się tutaj po prostu na tej liście.
Jest to ten mail, na który właśnie założyłeś tutaj konto w konsoli Google'a.
Możemy tutaj wgrać oczywiście logo aplikacji.
Nie jest to konieczne, ponieważ na razie będziemy tworzyć właśnie taki ekran i
taką aplikację tylko dla trybu testowego.
Kolejno musimy tutaj podać domenę aplikacji, a w zasadzie trzy adresy.
To jest adres strony głównej.
Ja tutaj usunąłem to versiontest.
Po prostu zostawiłem taką roboczą domenę tutaj.
Babla.
To jest strona z polityką prywatności i strona tutaj z warunkami.
Natomiast jak pamiętasz nie tworzyliśmy tych stron i nic się nie stało.
Tak jak mówię, na razie mamy tutaj konto testowe, więc musimy po prostu wprowadzić
tutaj jakieś strony, które nawet jeszcze nie muszą zostać dodane w serwisie.
Natomiast jeśli będziesz chciał potem opublikować taką swoją aplikację w
Google'u, czyli przejść przez proces weryfikacji, no to oczywiście
te strony będą musiały istnieć.
No i wtedy też zamienimy tą roboczą domenę babla już na taką właśnie naszą.
Natomiast na chwilę obecną pozostawiamy to właśnie w takiej formie.
Tutaj oczywiście wyskoczy Ci powiadomienie, aby dodać tą domenę tutaj
do tych autoryzowanych, więc ją sobie tutaj skopiuj, wstaw to
miejsce i kliknij Dodaj domenę.
W to miejsce wpisujesz adres kontaktowy do dewelopera.
Ja podałem dokładnie tego samego maila, którego mam tam wyżej, a więc
po prostu office@pastenessinfo.
I to wszystko, co musimy tutaj uzupełnić na tym pierwszym kroku.
Jeśli to już zrobisz, to klikamy Zapisz i kontynuuj.
I tym razem naszym zadaniem jest dodanie zakresów.
Czym są te zakresy?
To są dostępy do tego, co chcesz działać w ramach konta danego użytkownika.
Jak pamiętasz, Google ma ogromną ilość usług.
Mogą to być na przykład mapki Google, konta YouTube, konta na Google
Drive, kalendarze i tak dalej.
I tutaj właśnie wskazujesz, z których z tych usług chciałbyś w
imieniu użytkownika korzystać.
I te zakresy dzielą się na niewrażliwe oraz wrażliwe.
Na przykład.
Tak jak mówiłem, wrażliwym jest na przykład dostęp do kalendarza.
Na pewno wrażliwym będzie też konto Google Drive i tak dalej, czy też konto Gmail.
My natomiast dodajemy tylko trzy zakresy niewrażliwe, czyli takie ogólnodostępne,
bo tylko takie ogólnodostępne informacje będą nam potrzebne, aby
zalogować użytkownika.
A więc tutaj klikasz dodaj lub usuń zakresy.
I zaznaczasz te trzy pierwsze czyli userInfo.
i email userInfo.
profeel oraz Open ID.
Zaznaczasz sobie te trzy opcje i klikasz tutaj zaktualizuj.
Wtedy one powinny tutaj wskoczyć.
Nie korzystamy jak mówiłem żadnych zakresów wrażliwych.
Nie korzystamy tutaj żadnych zakresów z ograniczeniami.
Dodajemy tylko te trzy i klikamy Zapisz i kontynuuj.
Teraz możesz tutaj właśnie dodać użytkowników testowych, którzy będą
mieli dostęp właśnie do Twojej aplikacji.
Tak jak widzisz tutaj dozwolony limit to 100 w tym trybie testowym.
Jeśli chciałbyś właśnie dać dostęp tylko konkretnym użytkownikom, którzy muszą
oczywiście posiadać gdzieś tam konto w domenie Google'a, czyli w zasadzie konto
na Gmailu albo gdzieś na Google Workspace, to możesz tutaj po prostu
dodać add users i wymienić ich.
Ja natomiast z reguły zostawiam sobie to puste.
W ten sposób mogę testować właśnie różne swoje konta bez problemu, że
zapomniałem je tutaj dodać.
A więc pozostawiamy to w tej formie.
Tak jak mówiłem wcześniej, na razie jesteśmy w trybie testowym, więc możemy
to właśnie pozostawić w ten sposób.
Klikamy Zapisz i kontynuuj.
No i teraz przechodzimy do podsumowania.
Tak jak mówiłem tutaj aplikacja typu external i cała ta reszta, którą
wybieraliśmy na poprzednich krokach.
Kiedy to już jest gotowe, klikamy sobie Back to dashboard.
No i pierwszy krok za nami.
Ekran zgody Auth został utworzony, a my teraz będziemy mogli dodać
tutaj nasze dane do logowania.
Natomiast zanim to zrobimy, wracamy jeszcze do edytora Babel.
Przechodzimy do pluginów i musisz sobie dodać tutaj plugin o nazwie Google,
żeby go namierzyć, bo tych pluginów w Google jest bardzo dużo.
Klikasz Add plugins.
Zjeżdżasz na sam dół, odznaczasz to third party developers.
Czyli interesują nas wyłącznie te pluginy przygotowane przez właśnie Babel
i wpisujemy po prostu google.
i teraz bez problemu namierzyć ten plugin na liście.
Klikamy Install i to wszystko.
Kiedy taki plugin zostanie tutaj już dodany, musisz sobie na niego
kliknąć, żeby pojawiły się te opcje.
I to co musimy zrobić w pierwszej kolejności to zaznaczyć właśnie ten
checkbox, czyli use generic redirect URL, czyli taki właśnie generyczny
adres do redirectu.
Do tego jeszcze sobie potem przejdziemy i będziesz rozumiał w zasadzie co
to jest, do czego służy ta strona.
Na razie po prostu tylko zaznacz ten checkbox.
I tu niestety z jakiegoś dziwnego powodu nie da się skopiować tej wartości.
Natomiast ona będzie potrzebna.
A więc postaraj się przepisać sobie gdzieś ten adres.
To jest oczywiście stałe, to jest Twoja strona główna, więc możesz ją sobie po
prostu skopiować gdzieś z URL a, a potem dopisz to na API łamane na
1.1.1 i właśnie OAuth Redirect.
Kiedy już to zrobisz, czyli zaznaczysz ten checkbox i przepiszesz sobie gdzieś
właśnie adres URL, musimy wrócić do konsoli.
Tym razem przechodzimy tutaj do danych logowania i wcześniej
dodawaliśmy tutaj klucze API.
A teraz musimy kliknąć tutaj.
Utwórz dane logowania Identyfikator klienta OAuth.
Klikamy tutaj.
I tak wybieramy tutaj.
Aplikacja internetowa.
Tutaj podajesz nazwę znów Ona jest dowolna.
Będziesz ją widział tylko Ty.
I teraz będziemy musieli dodać tutaj odpowiednie wartości.
Ja już to zrobiłem wcześniej, a więc przejdę do tego klucza, który
będziesz musiał utworzyć u mnie.
Nosi on tutaj taką nazwę.
I tak jak mówię, podajesz nazwę i w to miejsce tutaj musisz wstawić właśnie ten
skopiowany wcześniej URL, czyli właśnie ten OAuth redirect.
Jeśli to zrobisz, klikasz zapisz i taki klucz powinien zostać
dla Ciebie utworzony.
Wtedy będziesz miał właśnie tutaj dostęp do identyfikatora klienta
oraz tajnego klucza klienta.
Natomiast jakbyś sobie zamknął to okno i nie zdążył tego skopiować.
Tak jak widzisz, wystarczy wtedy po prostu kliknąć na ten klucz tutaj na liście i te
informacje znowu nam się tutaj otworzą.
I to co musimy teraz zrobić, to skopiować te wartości, czyli ID oraz Client
secret do naszego pluginu Babel.
Czyli zaznaczamy sobie to pierwsze.
To jest identyfikator klienta.
Wracamy do edytora i wstawiamy to w to miejsce.
App ID apki, czyli tutaj oraz tutaj dla wersji produkcyjnej deweloperskiej.
My na razie korzystamy z tego samego, a więc wstawiamy to tu i tu.
Teraz wracamy tutaj, kopiujemy tą wartość albo klikamy tutaj
i znów wracamy do edytora i tym razem wstawiamy je tutaj w to
miejsce oraz to ja już to zrobiłem.
A więc właśnie tutaj ten plugin Google'a jest połączony właśnie z tym kluczem,
który sobie tam wygenerowałem.
Jeśli to już mamy zrobione, jeśli odpowiednio właśnie poustawiałeś te
wartości, to przechodzimy na stronę Sign up.
Ja już na niej jestem.
Przechodzę sobie tutaj do designu, klikam na ten button google button, klikam
edit workflow i będę tworzył właśnie nowy workflow.
Jak widzisz ja już je tutaj utworzyłem.
Przejdę sobie do odpowiedniego folderu.
I teraz tak po kliknięciu w ten button wybieramy tutaj z gotowych akcji social
i opcję Sign up Login with Social network.
Klikamy sobie to i wskazujemy providera.
U nas jest tylko jeden, czyli Google.
Ja już to zrobiłem, a więc wygląda to w ten sposób.
A skoro to mamy już tutaj zrobione, no to tak naprawdę to wszystko, co
potrzebowaliśmy do tego, aby móc logować i rejestrować użytkowników
właśnie poprzez Google'a.
Oczywiście to sam krok, czyli sign up login Google musiałbyś
dodać na stronie logowania.
Korzystamy z dokładnie jak widzisz tej samej akcji.
Niezależnie czy kogoś rejestrujemy czy logujemy w Google Bubble jest to
właśnie jedna i ta sama akcja.
I tutaj się ma dziać.
Oczywiście powinniśmy tutaj odpalić onboarding i tak dalej.
Ja natomiast właśnie po tutaj tej akcji.
Będę chciał przekierować użytkownika na razie na stronę dashboardu.
Nie bawię się tutaj żadnymi widokami, Chcę tylko wiedzieć właśnie, że rzeczywiście on
tutaj odpowiednio się zarejestrował albo zalogował i wtedy go kierujemy
właśnie do jego dashboardu.
No to zerknijmy, czy nam to teraz działa.
Odświeżamy.
Przechodzę na stronę Sign up.
Continue with Google.
Zostałem odpowiednio przekierowany.
Jeśli wszystko poustawiałeś, właściwie podpinałeś te klucze, to właśnie
powinieneś trafić na taką stronę.
Wybieram swoje konto.
Tak, chcę się zalogować.
Tu mamy oczywiście domenę roboczą Babel Apps, ale tym się nie przejmujemy.
Klikam dalej.
I zaraz powinienem trafić na stronę dashboardu.
Ok.
Oczywiście nie przeszliśmy onboardingu, więc nie mamy żadnych informacji o tym.
Ale tym się oczywiście nie przejmujemy, bo nasze główne zadanie zostało wykonane.
Czyli mogę się teraz wylogować?
I na tym w zasadzie moglibyśmy skończyć.
Ale tu pojawia się pewien problem, o którym większość tutoriali, jakie
znalazłem w necie zapomina wspomnieć.
Mimo, że jest to bardzo ważny fakt, a mianowicie wykorzystanie tej metody nie
pozwoli Ci utworzyć wcześniej konta użytkownika i potem na przykład zalogować
go z Google czy też zarejestrować.
Jeśli bowiem o tym nie wiedziałeś, to Cię teraz informuje, że Babal posiada opcję
utworzenia konta dla kogoś innego.
Wtedy tworzymy sobie takiego usera w bazie, przypisujemy mu tymczasowe hasło i
w ten sposób będzie mógł potem zalogować się do naszej aplikacji i wtedy oczywiście
powinniśmy też odpowiednio go poinformować o tym, aby zmienił sobie hasło z
tymczasowego na własne i tak dalej.
Natomiast tym się nie będziemy zajmować, ale wiem, że jeśli dopiero zaczynasz
przygodę z aplikacjami, to taka opcja wydaje Ci się pewnie teraz mało przydatna.
Natomiast uwierz mi na słowo, że tak wcale nie jest.
Bardzo często bowiem spotkasz się z wymogami klientów, którzy nie będą chcieli
mieć otwartej rejestracji w swoim serwisie.
I w takim przypadku to my tworzymy konto dla takiego admina w aplikacji.
Oczywiście on nie ma konta developerskiego, czyli nie widzi tego
całego zaplecza, z którym my mamy do czynienia, ale tworzymy dla niego osobny
dashboard i wtedy taki admin może się tam zalogować i zapraszać na przykład
nowych użytkowników do aplikacji.
Oczywiście wymaga to utworzenia odpowiedniego workflow, ale do
tego też sobie jeszcze przejdziemy.
I o ile wtedy korzystamy z obsługi użytkowników tylko i wyłącznie przez
samobabel, bez żadnych zewnętrznych serwisów, no to sprawa jest prosta.
Tak jak mówię, tam wystarczy proste workflow i to działa bezproblemowo.
Ale w przypadku, gdy w grę zaczynają wchodzić jeszcze zewnętrzne systemy
logowania czy też rejestracji, no to sprawa się już mocno komplikuje.
Dokładnie tak to właśnie wyglądało z klientem, o którym
wspominałem Ci na początku.
Jego wymogiem było to, aby użytkownicy właśnie logowali się wyłącznie za pomocą
Microsoft, a dodatkowo chciał, aby ich wcześniej dodać do aplikacji i
przyznać im odpowiednie role.
W ten sposób po zalogowaniu się mieli dostęp do odpowiednio
wyznaczonych części serwisu.
I właśnie tutaj natrafiłem na ten problem, że co prawda możemy bezproblemowo dodać
logowanie z Microsoft za pomocą pluginu, dokładnie tak, jak zrobiliśmy to przed
chwilą w przypadku Google'a, ale gdy najpierw dodałem takiego usera w
serwisie do naszej bazy danych, to przy próbie logowania czy też właśnie
rejestracji dostawał on komunikat, że takie konto już istnieje i koniec kropka.
I nie można było tego przejść.
Nie można tego było zmienić.
Niestety właśnie ta jedna opcja gryzła mi się z drugą.
Dlatego też pokażę Ci teraz nieco trudniejszy sposób na to, jak zalogować
czy też zarejestrować użytkownika z Google, ponieważ jak już doskonale
widziałeś, jest to w zasadzie jedno i to samo.
Gdzie wszystko to co robi plugin, my zrobimy teraz ręcznie.
Sami W ten sposób przekonasz się co tak na prawdę pod spodem robi ten plugin.
A jeśli w przyszłości będziesz chciał dodać do swojej aplikacji możliwość
dostępu do jakichś usług Google'a w imieniu usera?
No to będziesz miał już solidne podstawy do działania.
Pierwszym krokiem, jaki musimy teraz podjąć to dodanie nowej strony.
Czyli klikamy tutaj kolejno A new page.
Ja już taką stronę utworzyłem i u mnie nosi nazwę po prostu Redirect.
Teraz mogę Ci pokazać jak ona wygląda.
Jest super prosta.
Jedyne co tutaj zrobiłem to ustawiłem layout na ala parent, a tutaj dodałem
grupę a w środku tekst oraz loader.
Jeśli chcesz dodać też taki fajny loader jak ja mam tutaj to po prostu
zainstaluj odpowiedni plugin.
On się nazywa tutaj Animated loader i daje Ci chyba 5.
Tak, dokładnie 5 różnych właśnie takich loaderów, które możemy sobie wykorzystać.
Mi zależało na tym, że jeśli klient zostanie przekierowany właśnie na taką
stronę, to żeby nie widział tutaj po prostu białej kartki, a jakąś informację,
że tutaj po prostu wykonujemy pod spodem coś, coś się dzieje i żeby
chwilkę po prostu poczekał.
Tak więc daję Ci właśnie chwilę czasu, żebyś sobie dodał taką stronę z jakimś
tekstem i loaderem i zaraz przystąpimy do dalszej pracy.
Okej, mam nadzieję, że to już zrobiłeś i taka strona już tutaj została utworzona
i teraz będziemy musieli to wszystko zacząć spinać w całość.
Dlatego też przechodzimy do znanego Ci już narzędzia, które pokazywałem
wcześniej o nazwie Postman.
Jeśli go jeszcze nie pobrałeś i nie zainstalowałeś, to proszę zrób to w tym
momencie, ponieważ ja udostępnię w linku pod lekcją na społeczności.
Właśnie dostęp tutaj do takiego folderu, z tymi wszystkimi metodami, z których
będziemy korzystać tak, żebyś miał po prostu ułatwione zadanie i
go sobie szybko skopiować.
Naszym pierwszym zadaniem, pierwszym krokiem będzie utworzenie takiej strony
logowania, czyli to co dla nas robił plugin, czyli przekierowywał użytkownika
na taką stronę, gdzie tam wybieraliśmy konto Google'a i się logowaliśmy.
Teraz my musimy zrobić sami.
I tak. Skąd ja to w ogóle wziąłem?
Otóż wzorowałem się bardzo mocno na dokumentacji Google'a oraz oczywiście
sporo podpowiedział mi czat GPT.
Tutaj na dole Widzisz teraz link do dokumentacji.
Będziesz mógł sobie oczywiście doczytać te wszystkie szczegóły, natomiast moim
zdaniem jest ona bardzo mocno nieczytelna.
Zresztą te strony Google'a tak średnio wypadają, jeżeli chodzi o to, aby tutaj
coś rzeczywiście zrozumieć na samym początku.
Dlatego też to jest raczej jako ciekawostka,
zdecydowanie zalecam tutaj spojrzeć.
Natomiast jeśli będziesz postępował krok po kroku, to ja pokażę Ci, jak to wszystko
wdrażać tak, żeby na koniec zadziałało.
A więc wracamy sobie do Postmana i mamy tutaj pierwszą metodę.
Ona jest tutaj wrzucona i wygląda w ten sposób.
I tak część parametrów jest stała.
Nie będziesz musiał tutaj nic zmieniać, tak jak na przykład tutaj
Response type Scope.
Jak widzisz, są to dokładnie te same scope, które wybieraliśmy właśnie w tym
ekranie, czyli Open ID Profile oraz email.
Access Type zostawiamy na offline.
To jest taki dodatkowy parametr, który się przydaje, jeśli będziesz chciał
zaimplementować kilka takich na przykład systemów logowania i w każdym z nich
korzystać właśnie ze strony redirect.
W ten sposób możesz sobie tutaj przekazać dowolną wartość.
Ja tu wpisałem Google, ale możesz wpisać a, B, C, x, Y, z cokolwiek zechcesz.
I teraz tak bardzo dwie ważne rzeczy.
W to miejsce należy przekazać ClientID oraz Redirect URI.
Zacznijmy od tego drugiego, czyli Redirect.
Przechodzimy sobie do serwisu Babel na stronę Redirect, którą
dokładnie teraz utworzyłeś.
Klikamy Preview.
I kopiujemy sobie ten URL i wklejasz go właśnie w to miejsce.
Czyli w ten sposób ja pozbywam się z tego debug mode.
Z reguły nie korzystam właśnie z debuggera przy pracy, Czyli to powinno
wyglądać w ten sposób.
Oczywiście tutaj adres Twojej aplikacji.
Natomiast tak to powinno tutaj zostać.
Ja tą zmianę cofnę.
I teraz musimy jeszcze pobrać ClientID.
W tym celu wracamy sobie do konsoli tutaj.
Zamknijmy to chwilowo.
Przechodzimy do dane logowania i dodajemy nowy klucz, czyli
nowy identyfikator klienta OAuth.
Ja już to zrobiłem.
Mam go tutaj i różnią się tylko tym, że podajemy tutaj właśnie dwa inne adresy,
czyli jest to nasza po prostu strona redirect, a nie ta, którą tam
musieliśmy sobie skopiować z pluginu.
W tym przypadku dodałem tutaj tą wersję zarówno z debug mode jak i bez niego.
Na wszelki wypadek.
Tak jak mówię raczej korzystamy z tego, ale nie zaszkodzi, żeby ta tutaj
druga wersja też się znalazła.
Klikasz właśnie zapisz.
Tworzysz sobie taki klucz, tak jak zrobiliśmy poprzednio w przypadku pluginu
i teraz mamy dostęp właśnie do tych Clientid oraz Client secret, A więc w tym
przypadku kopiujemy sobie tą pierwszą wartość, czyli identyfikator
klienta lub też ClientID.
Przechodzimy do Postmana i wklejamy ją właśnie w to miejsce,
czyli pod tą wartość.
I w momencie kiedy to zrobisz, kiedy właśnie wstawisz tutaj własne clientid,
własny adres strony redirect, resztę pozostawiasz bez zmian.
Wtedy dopiero możemy sobie zaznaczyć cały ten adres tutaj, cały ten URL.
I teraz będziemy musieli właśnie taki skopiowany adres dodać w naszym serwisie.
A więc wracamy sobie do edytora.
Przechodzimy na stronę Sign up do Workflow.
Ja tak zablokuje sobie ten wcześniejszy.
Zostawię go tutaj, żeby właśnie mógł Ci służyć jako wzór.
to tam sobie kopiuję, wklejam to jeszcze raz i teraz mogę właśnie
wykorzystać tą drugą wersję.
Czyli tą. Odblokujmy ją teraz.
I tym razem właśnie tutaj.
Jako akcję wybieramy Open external website i jedyne co musimy tutaj zrobić to
właśnie wkleić ten skopiowany URL.
W ten sposób właśnie użytkownika będziemy kierować na taką stronę zewnętrzną
z logowaniem i rejestracją w Google.
A więc proszę zrób to, o czym mówię, wklej właśnie ten URL tutaj
i to jest nasz pierwszy krok z wielu, więc możemy sprawdzić, czy nam
to rzeczywiście zadziała.
A więc przechodzę sobie na stronę sign up i co tu się ma teraz wydarzyć?
Otóż po kliknięciu tutaj powinniśmy zostać poprawnie skierowani właśnie na stronę
tutaj, czyli zaloguj się przez Google.
Jeśli to wszystko dobrze poustawiałeś, nie pomyliłeś się, wstawiałeś odpowiedni
właśnie clientid redirect URL i zostawiłeś resztę bez zmian i tutaj odpowiednio
skopiowałeś ten URL i wkleiłeś to właśnie po kliknięciu w button powinieneś
zostać przekierowany tutaj.
Jeśli tak się nie dzieje to posprawdzaj czy rzeczywiście nie popełniłeś jakiegoś
błędu po drodze, czy dodałeś te adresy właśnie tam, przy tych kluczach?
Dokładnie tak jak Ci pokazywałem i ustawiłeś wszystko na tym ekranie.
Auf Tak jak pokazywałem na samym początku.
Natomiast jeśli to wszystko działa i jesteś tutaj, no to
jesteśmy na dobrej drodze.
Teraz znów mogę wybrać swoje konto i teraz po zalogowaniu się na to konto, które mam
tutaj, powinienem zostać przekierowany na ten adres URI, który podaliśmy w tym
miejscu, czyli właśnie w naszym przypadku na tą stronę Redirect, czyli tutaj,
właśnie tu musieliśmy podać ten adres, żeby Google wiedział gdzie
potem przekierować użytkownika.
A więc klikam.
Wygląda na to, że chyba wszystko jest ok.
Tak trafiliśmy na stronę Tutaj redirect.
Mamy loader, mamy nasz tekst.
No i co się teraz stało?
Otóż przede wszystkim zalogowaliśmy się w zewnętrznym serwisie.
To Google zadbał o to, żeby sprawdzić właśnie, czy ja to ja i czy
loguję się na odpowiednie konto.
Teraz przekierował mnie na stronę właśnie tutaj.
Redirect.
A to co dla nas jest najważniejsze, to musimy przejść teraz do paska adresu URL
i skopiujmy sobie po prostu tą wartość.
Wszystko to co tutaj mamy.
Ja na razie przejdę sobie o właśnie tutaj do wiadomości wkleję
to, co skopiowałem, ponieważ potrzebujemy tutaj jednej bardzo ważnej wartości, czyli
tego co otrzymujemy tutaj pod parametrem code.
A więc odtąd tutaj do tego znaczka Ampers and przed scope.
To jest kod, który prześle nam Google dopiero wtedy, kiedy
poprawnie się zalogujemy.
I teraz, kiedy mamy już właśnie ten kod, to będziemy mogli go wykorzystać dalej,
a wykorzystać go w kolejnej metodzie.
Przejdźmy do Postmana.
Ja tutaj przygotowałem dla Ciebie kolejną metodę i znów
ten kod będziemy przekazywać właśnie z tego, co otrzymaliśmy od Google'a.
To miejsce musi wstawić klient ID oraz klient Secret.
Czyli znów wracamy sobie do konsoli.
I tak to jest klient ID.
Tak jak było wcześniej, to jest klient secret.
Czyli kopiujesz to i wstawiasz tutaj pod Clientid.
Potem kopiujesz tajny klucz klienta, czyli tutaj wstawiasz w to miejsce redirect.
URI ma być dokładnie taki sam jak wstawiłeś sobie tutaj.
Czyli możesz po prostu zaznaczyć tą wartość, skopiować i
wstawić ją w to miejsce.
I teraz, kiedy już mamy przygotowaną właśnie taką metodę tutaj w Postmanie
poustawiałeś wszędzie te wartości, to musimy teraz to odwzorować w
naszym edytorze w API konektorze.
A więc wracamy oczywiście do Babla.
Przechodzimy sobie do pluginów API Connector.
Klikasz Add another API, aby utworzyć właśnie kolejną grupę.
Ja ją tutaj nazwałem Google.
I teraz mogę przystąpić do dalszego działania.
A więc klikam sobie Expand.
I mamy tak. Pierwszą metodę dodajemy tutaj nowe API.
Ja tą metodę nazwałem Exchange Code Token, ponieważ właśnie to ona będzie robiła.
Będziemy taki kod zamieniać na token, z którego potem będziemy korzystać.
I tak ustawiamy, że jest to action data type JSON.
Wywołujemy metodę typu post tutaj pod taki adres URL.
Możesz go po prostu skopiować sobie tutaj z postmana.
I kolejno tak. Dodajemy pierwszy nagłówek.
Znów masz go tutaj w Postmanie.
Header kopiujesz oraz value i wstawiasz tutaj w odpowiednie miejsce.
Czyli tutaj zaznaczasz private, ponieważ tego nagłówka nigdy nie będziemy zmieniać.
On musi zostać stały.
I następnie poprzez Add parameter dodajesz tutaj 1, 2 3 4 5 parametrów.
Gdzie tak dla każdego musisz zaznaczyć to query string koniecznie tutaj
I tak te dwa będą dynamiczne, czyli kod.
Będziemy sobie to pobierać z tego URL i przekazywać tutaj oraz redirect URL.
To specjalnie zostawiłem właśnie tutaj z odznaczonym private.
Co prawda teraz podczas tej lekcji będziemy korzystać tylko
z tego jednego adresu.
Natomiast w przyszłości, kiedy będziesz właśnie już publikował aplikację i tak jak
mówię, będziesz miał wtedy adresy i developerskie, i produkcyjne, no to
będziesz mógł tutaj przekazać właśnie odpowiednią wartość.
Zresztą pokazywałem to w lekcji z wysyłaniem maila tam, gdzie mieliśmy
właśnie ten login link i pokazywałem Ci właśnie jak wysłać to dla wersji tutaj
developerskiej, potem produkcyjnej.
A więc tak tutaj kod i w to miejsce musisz wstawić ten skopiowany kod.
Czyli wróćmy sobie o właśnie tutaj.
Zaznaczmy, skopiujmy.
Wstawiasz go w to miejsce, odznaczasz private.
Zaznaczasz query string redirect URI.
Kopiujesz sobie z postmana.
Stawiasz, Oznaczasz.
Private Zaznaczasz QueryString i analogicznie robisz właśnie dla tych
trzech parametrów, czyli kopiujesz właśnie to co sobie poustawiałeś tutaj, czyli Twój
klient id client secret oraz właśnie ten stały parametr grant type.
No i teraz musimy oczywiście zainicjować taką metodę, czyli zaznaczamy
tutaj i zobaczysz co się stanie.
Klikam tu.
No i dostaję komunikat o błędzie I muszę przyznać, że jego rozwiązanie
zajęło mi dzisiaj ponad półtorej godziny, nim namierzyłem właśnie,
co tu jest nie tak?
Już w którymś momencie zacząłem podejrzewać jakiś spisek Google'a, a
odpowiedź jak zawsze okazała się wyjątkowo prosta.
Ale niestety takie są najtrudniejsze czasami do namierzenia.
Otóż okazuje się, że problemem nie jest właśnie cała ta nasza metoda, a to, co
przed chwilą skopiowaliśmy i wstawiliśmy tutaj jako kod.
Zobacz co tu się dzieje.
Mam 4 procent i dwójka.
Musisz wiedzieć o tym, że w pasku adresu URL te wartości, które tutaj wpisujemy,
tak jak widzisz często są kodowane.
Po prostu URL zamienia takie niedozwolone wartości jak przecinki,
slash, spacje, cokolwiek, co nie powinno się tutaj znaleźć właśnie jest kodowane.
No i niestety dokładnie to samo stało się tutaj z tą wartością, z tym naszym kodem.
Mimo, że ona jest poprawna, to została właśnie odpowiednio zakodowana i
dlatego teraz nam to nie wskakuje.
Co możemy w takiej sytuacji zrobić?
Otóż musimy przejść pod taką stronę.
Tutaj adres widzisz na dole ekranu, czyli URL dekoder enkoder.
Wstawiamy sobie to tutaj.
Klikamy decode i zobacz co się tutaj stanie na samym początku.
Widzisz, ten procent nam tutaj zniknął i pojawił się ten znaczek,
który powinien być.
A więc dopiero taką wartość możemy sobie skopiować, wrócić
tutaj, wstawić w to miejsce.
I teraz jeśli kliknę inicjalizację, no to dopiero dostaję prawidłową odpowiedź.
Klikamy save.
Tutaj nic nie zmieniamy.
Tak jak mówiłem w poprzedniej lekcji, Babel tworzy taki snapshot, czyli tego
co ma się spodziewać w odpowiedzi.
I tu właśnie na pierwszym miejscu mamy access token, z którego potem będziemy
korzystać, a więc klikamy po prostu save.
Natomiast gdybyś zamiast tego błędu, który Ci pokazałem, dostał jakąś informację, że
ten kod wygasł cokolwiek z expair lub coś takiego, to oznacza po prostu tylko tyle,
że za długo zajęło Ci skopiowanie go i wklejenie.
Tutaj ten kod, który otrzymujesz, czyli ten, który otrzymujemy tutaj na
stronie redirect jest ważny z tego co pamiętam chyba tylko kilka minut.
Tak więc jeśli taką informację dostaniesz, no to przejdź sobie jeszcze
raz na stronę Sign up.
Jeszcze raz kliknij button Continue with Google, tak żebyś znów został skierowany
na stronę redirect z nowym tym kodem.
Wtedy go sobie tutaj odpowiednio skopiuj, ewentualnie dekoduj tak jak
Ci przed chwilą pokazałem.
I wtedy wklej tutaj.
I ta metoda tutaj powinna zadziałać.
Ok, skoro pierwszy krok mamy z głowy, czyli zamieniliśmy ten kod na token,
no to teraz będziemy musieli właśnie taki token wykorzystać.
O tokenach zresztą już sobie rozmawialiśmy.
Pamiętasz, mówiłem ci w poprzednich lekcjach, dlaczego on jest przydatny.
No właśnie po to, żeby się autoryzować.
Żeby aplikacja, na którą właśnie wysyłamy jakiś request pod jakiś adres
URL, wiedziała, że my to my.
I wtedy decydowała, czy rzeczywiście zwrócić tam jakieś dane, czy po
prostu zablokować taki dostęp.
A więc tutaj dostaliśmy kod, zamieniliśmy na token i teraz dodajemy
sobie nową metodę.
Ja ją nazwałem Get UserInfo, ponieważ tylko to właśnie będziemy robić.
Teraz musimy pobrać na podstawie takiego tokenu informacje jakiego
usera to w zasadzie dotyczy.
A więc klikamy Expand dodaje tutaj nową metodę i tak znów jest to action.
Znów jest to JSON.
Tym razem jest to get taki adres URL.
Jedyne co musimy tutaj dodać to ten nagłówek Authorization,
już Ci zresztą znany.
Kolejno brr i spacja.
I dopiero tutaj wklejamy właśnie ten access token, który tu otrzymaliśmy.
Jeśli go sobie nie skopiowałeś, a tutaj odpowiednio to uruchomiłeś, to klikasz w
to miejsce i właśnie otrzymujesz odpowiedź, co to zostało
zwrócone właśnie w tym zapytaniu.
I nas interesuje ta część.
Tutaj access token jest dwukropek i między tym cudzysłowem ta wartość.
Pamiętaj, żeby nie zaznaczyć tego cudzysłowia i dokładnie zaznaczyć tu całą
wartość, ponieważ ten token musi być pełen.
Jeśli go tam źle przekażesz, no to oczywiście to nie zadziała.
Czyli zaznaczamy sobie to, kopiujemy i wstawiamy tutaj, czyli brr spacja.
Tutaj ten token.
Tu oczywiście odznaczamy private, ponieważ będziemy go za każdym razem generować.
Będziemy go przekazywać dynamicznie.
Kolejno zaznaczamy ten checkbox.
No i znów ten button, żeby to zainicjować.
Ja już to zrobiłem i w odpowiedzi powinniśmy dostać coś takiego.
Czyli jak widzisz, tutaj mam informacje o użytkowniku, do którego taki token należy,
czyli w tym przypadku moje konto, czyli mój e-mail, imię, nazwisko i nawet
obrazek, który mam gdzieś tam ustawiony na koncie Google'a.
Skoro to mamy już gotowe, czyli zamieniliśmy kod na token, a potem za
pomocą tokenu pobraliśmy sobie informacje o użytkowniku, no to musimy
teraz to pospinać w całość.
Klikam tutaj cancel.
Mamy te dwie metody, które będziemy zaraz wykorzystywać i w tym celu przechodzimy
sobie do Back and Workflow.
I dodajemy nowe API workflow.
Ja już je tutaj dodałem, A więc mogę to zamknąć.
Ja je nazwałem po prostu Google.
I teraz zobacz, co musimy tutaj zaznaczyć.
Przede wszystkim tym razem to API będzie publiczne.
Do tego jeszcze wrócimy i porozmawiamy sobie dlaczego.
A więc zaznaczamy ten checkbox.
Odznaczamy ten.
Będziemy wymagać autoryzacji, aby użytkownik mógł właśnie tutaj wysłać nam
jakiś request, ale zaznaczamy sobie ten, czyli ignorujemy Privacy rules.
A więc pierwszy zaznaczony, drugi odznaczony, trzeci zaznaczony.
Zostawiamy post i dodajemy tutaj parametr o nazwie Code i tym razem będzie to tekst.
I teraz tak.
Pierwszym krokiem będzie wywołanie tej pierwszej metody, którą dodaliśmy
właśnie, czyli Exchange Code token.
I tutaj przekazujemy sobie dynamicznie ten kod.
Tak jak mówiłem, później będziesz mógł tutaj przekazywać dynamicznie ten direct,
ale ja na razie po prostu zostawiam to w tej wersji, jaką tam mieliśmy dodaną.
Czyli tak, tutaj zamieniliśmy ten kod na token.
I jako drugi krok wywołujemy kolejną metodę, którą właśnie dodaliśmy w
API kolektorze, czyli Get UserInfo.
I tym razem właśnie przekazujemy tutaj ten token.
Czyli mamy brr spacja i właśnie Access token pobrany z tego pierwszego kroku.
Czyli jeśli to usunę to mam Result of step on body access token.
Jeśli wszystko dobrze poustawiałeś, to właśnie pod tym parametrem
powinieneś mieć token.
I teraz kolejnym krokiem jest to, o czym mówiłem Ci już wcześniej, czyli
tworzymy konto dla kogoś innego.
Tutaj właśnie mamy teraz informację, jaki mail do nas trafił, jaki użytkownik
się loguje albo rejestruje.
A więc wybieramy tutaj tą opcję Create account for someone else
I co jest mega ważne, a o czym chyba zapomnieli po prostu twórcy tego
pluginu to zaznaczenie tej opcji.
Czyli jeśli takie konto już istnieje, czyli jeśli użytkownik będzie się logował,
a nie rejestrował, to my je po prostu zwracamy.
Gdybym odznaczył tą opcję i próbował właśnie się znowu tutaj zalogować.
No to system zwrócił mi komunikat, że taki mail już istnieje, a próbuję dodać kolejne
konto i to niestety w Babel nie przejdzie.
A więc zaznaczamy ten checkbox i tutaj email to jest result of step tu
i body e-maila.
Znów jeśli to ustawiałeś, to właśnie taki parametr powinieneś tutaj mieć.
I tak teraz na tym kroku utworzyliśmy albo po prostu zwróciliśmy już istniejące
konto mając właśnie odpowiedniego maila.
I teraz wybieramy tutaj kolejną akcję A sign password to user.
Tym razem właśnie tworzymy takie tymczasowe hasło i przypisujemy do tego
użytkownika, którego tutaj stworzyliśmy.
I teraz ostatnim krokiem tutaj na tej liście będzie return data from API,
czyli zwracamy po prostu właśnie coś z takiego zapytania.
I w tym przypadku zwracamy sobie to tak z JSON i dodajemy dwa parametry email.
Tu jest text password, tu jest text i tutaj dla email E-mail.
Oczywiście będzie to rezultat Step 2.
Oczywiście mógłbyś wyciągnąć sobie też email z kroku nr 3.
To nie ma najmniejszego znaczenia.
Najważniejsze jest to, żebyśmy przekazali prawidłowy e-mail.
I tutaj pod password zwracamy właśnie sobie to, co tutaj wygenerowaliśmy w tym
kroku numer 4, czyli właśnie takie tymczasowe hasło.
I teraz mając email oraz password będziemy mogli właśnie na podstawie takiego back
and workflow wyciągnąć te wartości i po prostu zalogować użytkownika
w naszym serwisie.
Dokładnie to będziemy właśnie teraz robić na stronie tutaj redirect.
Natomiast jeśli na nią przejdę.
Czyli przechodzę na redirect, to mam już gotowe właśnie takie workflow.
Do tego jeszcze przejdziemy, ale najpierw zobacz jaki mamy tutaj warunek.
Wybieram sobie tak jak tu condition is just when i warunek to
w naszym przypadku tak.
URL, czyli get data from DataFrame. PageUrl.
Parametr o nazwie Kod.
Nie może być pusty, czyli is not empty.
Czyli otrzymaliśmy poprawnie ten kod.
Gdyby użytkownik się tam nie do końca zalogował, nastąpiły jakieś problemy, to
ten parametr kod po prostu nie wróci na naszą stronę Redirect.
I dodatkowo jeszcze tak jak mówiłem, jeśli będziesz miał tutaj kilka serwisów, no to
możesz sobie porównać ten drugi parametr.
Czyli u mnie właśnie Get state from PageURL jest po prostu równa Google.
I teraz może zróbmy to w ten sposób jeszcze raz.
Dodajmy sobie to tak Ok, skopiujmy sobie to
tak, żebyś widział, jak to się rozpoczyna.
A więc tak, mamy trigger.
No i teraz tak powinieneś pomyśleć o tym. Okej.
Utworzyliśmy do back end workflow AWS o nazwie Google.
No to możemy je sobie teraz tutaj wykorzystać.
A więc wybieramy ul.
Wybieramy Google.
Przekazujemy ten kod z URL a.
Czyli wartość parametru code.
Current date time.
Ignorujemy prawa cirrus.
No i tak jak mówiłem, stworzyliśmy to backend workflow AWS.
Zrobiliśmy to, co powinniśmy tam zrobić.
Na koniec zwracamy email i password.
No i teraz powinniśmy tutaj zalogować sobie użytkownika, czyli
po prostu logde user in.
No i oczywiście wyciągnąć to email i password z tego właśnie pierwszego kroku.
Natomiast zobaczmy co się stanie.
Wybieram sobie Result of Step 1 i nie mam ani e-maila, ani
hasła, ani niczego innego.
Mogę wybrać tylko to, co W zasadzie takie back end workflow mi teraz tutaj zwróciło.
Otóż zwróciło mi swoje ID.
I właśnie niestety tak to działa w Babel, że jeśli właśnie wybierzesz tutaj z API
workflow, to ono zwróci Ci tylko i wyłącznie swoje ID.
No i mógłbyś się teraz zastanowić w zasadzie do czego nam to ID jest
tutaj w ogóle potrzebne w Babel?
Po co mi ID takiego workflow?
Otóż jest to niesamowicie przydatna funkcjonalność.
A już Ci mówię dlaczego.
Jak pamiętasz, w naszym serwisie nie usuwamy konta użytkowników od razu.
To było na samym początku w pierwszym module, gdzie po kliknięciu
Delete Account my oznaczamy je jako do archiwizacji i trzymamy takie
zarchiwizowane przez 60 dni, tak żeby użytkownik jak się rozmyśli
mógł w każdej chwili wrócić.
No i jeśli chodzi o logikę powinno to wyglądać w ten sposób.
Użytkownik klika kilka kont, my oznaczamy flagę is archived i od razu ustawiamy
sobie workflow, które uruchomi się 60 dni później i po prostu usunie takie konto.
Natomiast co by się stało jakby użytkownik stwierdził po tygodniu ok, jednak
chyba nie chcę usuwać konta.
No i znów się loguje w naszym serwisie i dalej normalnie z niego korzysta.
Pod spodem dalej mamy aktywne to workflow, które ma za 60 dni wywali konto.
No i jakoś musimy to sobie teraz zablokować albo cofnąć.
No i właśnie tutaj przydaje się to ID.
Mógłbyś właśnie potem dodać jakąś kolejną metodę, kolejne workflow,
które by sprawdzało, czy jeśli użytkownik się loguje, a jego konto jest oznaczone
jako is archive, czyli mamy już właśnie zaplanowane takie workflow, któremu usunie
to konto za 60 dni, no to mając jego ID możesz sobie to cofnąć.
Wystarczy, że tutaj skorzystaj z tej akcji plugins, a w zasadzie custom event.
O właśnie cancel a apply workflow.
I tu przekazujesz tylko właśnie ID takiego workflow i to wszystko.
Tak więc widzisz, to ID bywa niesamowicie wręcz przydatne, ale tak jak mówię do
takiego blokowania czy też kontrolowania właśnie takich zaplanowanych workflow.
Natomiast u nas.
No właśnie u nas to do niczego się nie przyda.
My chcemy sobie wyciągnąć to email oraz password, które właśnie takie
API workflow powinno nam zwracać.
No i ono rzeczywiście je zwraca, ale dopiero wtedy, kiedy rzeczywiście wywołamy
taką metodę poprzez API konektora.
Dlatego też właśnie ustawiłem je jako dostępne w sieci, czyli usuńmy
sobie to jeszcze raz na chwilę.
Wróćmy właśnie na backend Workflow SE, czyli właśnie ten checkbox, że
to API jest dostępne publicznie.
Natomiast oczywiście zablokowaliśmy tutaj dostęp właśnie, nie
zaznaczając tego checkbox.
No i teraz jak wywołać swoje własne API workflow?
Jest to super proste.
Przechodzimy sobie do settingsów zakładka API.
I tak jak Ci mówiłem musimy sobie skopiować ten route URL czyli tą wartość.
Teraz przechodzimy do pluginów.
To mogę już tutaj pozamykać.
Ja już taką metodę sobie tutaj dodałem.
Czyli dodajesz po prostu nowe zapytanie i tak wstawiamy ten bazowy adres URL,
czyli ten łamane na nazwę naszego workflow.
O tym też już wspominałem w poprzedniej lekcji, że właśnie w taki sposób mamy
tutaj dostęp do naszych własnych kont workflow, a w zasadzie
naszych własnych API.
I tak jest to oczywiście akcja JSON.
Metoda post.
Dodajemy nagłówek Authorization, ponieważ oznaczyliśmy właśnie ten checkbox, gdzie
mówimy, że żeby uruchomić takie backend workflow użytkownik musi być autoryzowany.
No i teraz tak. Authorization Brr.
No i skąd wziąć ten token?
Znów już Ci to wcześniej pokazywałem.
Robimy dokładnie to samo, co robiliśmy na make, czyli generujemy nowy token.
I to jest kolejna bardzo ważna zasada.
Jeśli właśnie będziesz generował takie tokeny, czy to właśnie pod make, czy dla
siebie, czy też dla jakichś innych użytkowników, zawsze twórz osobny
token i zawsze go dobrze nazwij.
W ten sposób zapewniasz sobie możliwość prostej blokady dostępu
do Twojej aplikacji.
Czyli jakbym teraz chciał wyłączyć make, bo uznał, że coś tam jest nie tak, to
wystarczy, że po prostu usunę ten klucz.
Tak samo gdybym miał dostęp jakiejś grupie użytkowników np.
Do testów.
I te testy się zakończyły, a ja chcę zablokować im dostęp, to usuwam ten
klucz, a te pozostałe dalej działają.
One działają niezależnie i niezależnie właśnie czy wykorzystam ten, czy
wykorzystam ten, to i tak dostanę dostęp do mojej aplikacji.
A więc ja dodałem tutaj kolejny o nazwie Internal.
Teraz mogę sobie skopiować tą wartość.
No i skoro wymagamy tokenu, no to rzeczywiście musimy go tutaj wstawić.
Czyli znów brr spacja i nasz własny token wygenerowany tutaj wewnątrz aplikacji.
On będzie stały, więc zaznaczamy sobie tutaj private.
I tak jak mówiłem, jedyny parametr, który przekazujemy do tego backend workflow
to jest właśnie ten kod.
Dodajesz tutaj kod i żeby to znowu się uruchomiło poprawnie, musisz na nowo
przejść na stronę sign up, znów się tam zalogować przez Google'a, otrzymać nowy
kod i go tutaj sobie wstawić tutaj.
Nic więcej nie zaznaczamy.
On będzie tutaj dynamiczny, więc odznaczamy Zaznaczamy private
i znowu reszta checkboxów jest pusta.
Jeśli odpowiednio to uruchomisz tam wszystko powinno zadziałać, to powinniśmy
otrzymać właśnie taką odpowiedź.
Nas najbardziej interesuje ta część, czyli email oraz password.
Mamy właśnie e-maila użytkownika, którego powinniśmy zalogować i mamy tymczasowe
hasło, które za każdym razem będziemy po prostu zmieniać.
Czyli za każdym razem jak on się będzie logował z Google'a, będziemy tu tworzyć
właśnie takie tymczasowe hasło na ten okres jego pobytu i on będzie mógł
sobie wtedy po prostu z niego korzystać.
A więc klikamy cancel, skoro to już mamy gotowe.
Czyli utworzyliśmy właśnie takie pierwsze API dostępne na zewnątrz i dodatkowo
jeszcze je tutaj wywołaliśmy i uruchomiliśmy, no to nie pozostaje nam nic
innego jak pospinać teraz to wszystko w całość.
A więc w tym celu przechodzimy na stronę Redirect.
Do Workflow i tym razem mogę odblokować to właściwe.
I tutaj wywołujemy sobie właśnie to zapytanie API, które dodaliśmy, czyli to,
które uderza właśnie pod nasze backend workflow.
Jak widzisz, teraz mogę właśnie odnieść się do Result of Step 1 i wyciągnąć
sobie email oraz password.
Innymi słowy po prostu zalogować użytkownika.
I to by było wszystko, co musieliśmy teraz zrobić, aby właśnie takie logowanie slash
rejestracja z Googlem ustawiona właśnie przez nas ręcznie zadziałała.
I tu oczywiście możesz sobie pogratulować, ponieważ stworzyłeś swoje pierwsze API
dostępne z zewnątrz, a nawet właściwie pierwszy web hook, bo jest to tak jak
wspomniałem w poprzedniej lekcji po prostu adres internetowy, który tym razem to my
wystawiliśmy na zewnątrz, a który czeka, aby otrzymać dane i
wykonać jakąś operację.
Ok, a skoro właśnie to mamy gotowe, to teraz pewnie zastanawiasz
się, co się dzieje tutaj.
Mamy tutaj jakiś onboarding From Ere Login I from Re Otóż już Ci
mówię, co się tutaj zadziało.
Jeśli przejdę sobie na stronę sign up.
I teraz wybiorę tutaj tą standardową rejestrację użytkownika, no to jak
pamiętasz mamy tutaj trzy akcje.
Rejestrujemy takiego usera przypisując mu ten pin code, czyli taki
calculate random string.
Potem wysyłamy tego maila tutaj z tym kodem i kolejno kierujemy
go na stronę onboardingu.
No i dokładnie teraz to samo powinniśmy zrobić właśnie na tej stronie Redirect.
Jak ten użytkownik nam się tam zarejestrował?
No i nie pozostałoby nam nic innego jak po prostu skopiować te kroki, przynajmniej te
dwa, czyli wysłać tego maila, a potem skierować go na stronę onboardingu.
A potem oczywiście to samo musielibyśmy zrobić dla logowania, czyli właśnie to
kierowanie na odpowiednią stronę dashboardu.
W zależności od tego, czy mamy do czynienia z kontem gościa,
czy też kontem hosta.
I tu właśnie natrafiamy na ten jeden zasadniczy problem, który bardzo często
ludzie wytykają na różnych forach, że w programowaniu występuje zasada
dry, czyli don't repeat yourself.
A tu musimy się znów powtarzać, musimy generować te same akcje na różnych
stronach, te same workflow.
No i trochę się to kłóci z tą zasadą.
Myślę, że się zgadzasz.
Ja też się z tym zgadzam.
Natomiast nie zgadzam się z tym, że to właśnie tak powinno działać.
Otóż jeśli mamy jakieś powtarzalne właśnie workflow, tak jak mamy tutaj to zrobione,
to możemy sobie to przerzucić do reuowanego elementu.
Wystarczy, że w tym celu utworzymy nowy element.
Ja już go utworzyłem, nazywam go po prostu Jurę.
Wtedy wiem, że to są właśnie takie akcje, które są powtarzalne na różnych stronach.
I tutaj tak dla designu nie ustawiamy absolutnie nic.
Ja mam tutaj fixed 20x20 pikseli tylko po to, żeby tutaj można było w to kliknąć.
To nie było takie małe, jedno pikselowe.
I teraz przechodzimy sobie do Workflow i tutaj wybieramy Custom i Create a custom.
I w ten właśnie sposób musimy tutaj rozpocząć wykonywanie takiego workflow.
I teraz możemy je sobie jakoś nazwać.
Ja już je tutaj dodałem i pierwsze to onboarding.
I to co robię tutaj, to przekazuję tylko jeden parametr, a jest nim user.
I teraz w pierwszym kroku przypisuję ten pin code.
Czyli nie będziemy tego robić na samym momencie rejestracji, ponieważ w przypadku
Google'a nie mamy do tego dostępu.
Dlatego właśnie ja sobie przeniosłem tutaj to jako osobny krok,
czyli make changes a thing.
Wybierasz sobie user.
Teraz przypisujemy ten kod PIN.
Kolejno wysyłamy maila tutaj właśnie z tym kodem.
No i na trzecim kroku to, co robiliśmy wcześniej.
Kierujemy go na stronę onboardingu.
W przypadku logowania robimy niemal dokładnie to samo, czyli przekazujemy
sobie usera i tak jak wcześniej kierujemy go na stronę dashboardu
albo do tego widoku Guest.
Jeśli user type jest równy guest, albo oczywiście do widoku hosta,
jeśli ten usertype jest równy host.
I to co jeszcze tutaj dodałem to Google Page, czyli właśnie otwieranie
tej zewnętrznej strony w Google'u.
Ponieważ tą akcję Open External Website będziemy musieli dodać zarówno na stronie
logowania, jak i na stronie rejestracji.
Więc żeby się nie powtarzać i dodatkowo ułatwić sobie życie, gdybyśmy
musieli tutaj coś pozmieniać.
Właśnie tworzymy sobie taki Jirre.
I to będzie nasze jedyne źródło prawdy, jeśli chodzi właśnie o takie
powtarzalne akcje w naszym serwisie.
No ale dobrze, jak je teraz wykorzystać, jak już je tutaj podstawiamy,
czyli utwórz właśnie ten boarding.
Utwórz login, utwórz googlepage i kiedy to będzie już gotowe, to przechodzimy w
pierwszej kolejności na stronę Sign up.
No i teraz musimy gdzieś tutaj w designie dodać sobie właśnie taki element.
Ja go wrzuciłem tutaj do grupy Left.
Ona była ustawiona na All in the parent.
Na środku mamy ten ładny formularz, a tutaj w lewym górnym
rogu właśnie ten element.
Tam nic nie ma, więc nic nam się na stronie nie wyświetli, niczego
nie popsujemy w designie.
Natomiast skoro taki element jest już tutaj dodany, to my będziemy mogli sobie
wywoływać te właśnie custom eventy, które tam zdefiniowaliśmy.
A więc przechodzę sobie do workflow.
Tu mamy właśnie chyba ten tag.
Tu mamy ten, gdzie otwieraliśmy po prostu ten external website.
Teraz to blokuję.
Tu mam osobny.
Znowu sobie skopiowałem taką akcję, wkleiłem tą poprzednią zablokowałem, żebyś
mógł sobie w każdej chwili sprawdzić jak to było robione krok po kroku.
I teraz tak.
Wybieram sobie tutaj Custom Events i Trigger a custom event
from Isabel Element.
Jak widzisz teraz namierzyła mi ten Isabel element, ale tylko ten
mam chwilowo na stronie.
No i teraz mam dostęp do tych wszystkich custom eventów, które sobie
właśnie tam zdefiniowałem.
A więc w tym przypadku po kliknięciu w ten button chcę uruchamiać właśnie ten
custom event o nazwie GooglePage.
Natomiast po kliknięciu w ten button sign up znów zerknijmy czy mamy to.
Ok, blokujemy to.
Odblokujmy to.
I tym razem właśnie wywaliłem przepisywanie tego kodu PIN w tym
momencie tutaj rejestrujemy użytkownika.
I tutaj odpalamy sobie właśnie ten custom event przekazując go tutaj w
to miejsce pod parametr user.
I właśnie w tym evencie najpierw przypiszemy PIN, potem wyślemy maila, a na
koniec skierujemy go na stronę po prostu onboardingu.
Mam nadzieję, że rozumiesz jak to działa i jak właśnie niesamowicie
przydatna jest ta funkcjonalność.
W ten sposób się nie powtarzamy.
Stosujemy w praktyce zasadę Dry, a dodatkowo ułatwiamy sobie życie, bo nie
musimy właśnie zmieniać tych eventów na różnych stronach, jeśli
one się nam powtarzają.
Teraz przechodzę na stronę Sign in.
I znów tutaj po kliknięciu w ten button uruchamiam sobie
dosłownie to samo, czyli Google Page.
Oczywiście znów będziesz musiał dodać to na stronie.
Sign in.
Analogicznie robimy tutaj to dla buttonu z logowaniem, czyli logujemy użytkownika i
potem sprawdzamy czy on skończył już onboarding.
Jeśli nie, no to odpalamy właśnie onboarding z tych akcji custom eventów.
A jeśli finished onboarding jest równa? Jest.
No to pozwalamy sobie tutaj to logowanie.
Mam nadzieję, że rozumiesz dlaczego ustawiliśmy to w ten sposób.
Jeśli przerwał właśnie ten boarding i potem próbuje się znowu zalogować do
aplikacji, no to znowu go do niego skierujemy.
A jeśli go przeszedł, no to trafi właśnie na właściwą stronę dashboardu za
pomocą właśnie tego custom eventu.
I analogicznie to samo będziemy musieli zrobić teraz na stronie Redirect,
a więc tutaj po zalogowaniu użytkownika znów albo trafia na stronę gangu, albo
trafia na stronę właściwego dashboardu.
Mam nadzieję, że teraz, kiedy już rozumiesz, jak działa pod spodem cała ta
obsługa usera poprzez zewnętrzny serwis, okazuje się, że nie jest to aż tak trudne.
Dodatkowo te właśnie powtarzalne workflow przerzuciliśmy sobie do
jednego russa element.
Natomiast ja dodałem tą lekcję nie tylko po to, byś mógł potem wykorzystywać na
przykład Google do logowania, ale również po to, byś przygotował się mentalnie do
tego, co nas czeka w przyszłych lekcjach, gdzie na scenę wkroczy już Stripe, który
również wymaga całkiem sporej ilości zapytań i obsługi przez Webhooki.
Natomiast zanim przejdziemy już tutaj do końca tej lekcji, no to przetestujmy,
czy nam to wszystko działa.
Poustawialiśmy właśnie te custom eventy, poustawialiśmy tutaj właśnie te
backend workflow z zapytaniem do API.
No to czas na testy.
Wróćmy sobie na stronę główną.
Czyli pozbądźmy się tego.
Ok, nie jesteśmy zalogowani.
Zerknijmy czy ja mam tego usera jeszcze w bazie.
Ok, chcę wywalić swojego i chcę po prostu przejść przez cały proces
rejestracji, czyli klikam delete.
No i teraz spróbujmy się zarejestrować przez serwis Google.
Powinniśmy oczywiście trafić na stronę od brandingu.
Klikamy Continue.
Wybieram swoje konto.
Najpierw strona redirect.
To się zgadza.
I jesteśmy tutaj na stronie od brandingu.
Czyli wszystko wykonało się poprawnie.
Powinienem otrzymać maila.
No i teraz muszę oczywiście zweryfikować ten adres mailowy, no i
przejść przez cały onboarding.
Tak więc jak widzisz chwilę nam to zajęło.
Jest to chyba jedna z najdłuższych lekcji w tym kursie, ale mam nadzieję, że
wytrwałeś do końca i teraz rozumiesz jak to wszystko działa.
A ja dziękuję Ci serdecznie za uwagę.
No i widzimy się już w kolejnych lekcjach.