Logowanie bez hasła za pomocą linków magicznych — lista kontrolna UX i bezpieczeństwa

Czym jest logowanie przez link magiczny i co może pójść nie tak

Link magiczny to jednorazowy link do logowania wysyłany na e‑mail. Zamiast wpisywać hasło, otwierasz wiadomość, stukasz link i zostajesz zalogowany.

To dobre rozwiązanie, gdy użytkownicy nie lubią haseł, często je zapominają albo logują się rzadko. Może też ograniczyć powtarzanie haseł między serwisami, bo hasła w ogóle nie ma. Nie zwalnia to jednak z dbania o bezpieczeństwo — główny „klucz” po prostu przenosi się do skrzynki e‑mail użytkownika.

To jest główny kompromis: logowanie bez hasła za pomocą linków magicznych jest tak bezpieczne, jak bezpieczna jest skrzynka e‑mail użytkownika i jego zdolność do zachowania prywatności dostępu do niej. Jeśli ktoś ma dostęp do twojej poczty, często może się zalogować w twoim imieniu.

Oto najczęstsze sposoby, w jakie linki magiczne zawodzą w praktyce:

• Dostęp do skrzynki jest przejęty (phishing, SIM swap do odzyskiwania maila, malware lub współdzielony komputer pozostawiony zalogowany).
• Link zostanie przekazany dalej (celowo lub przez przypadek) i użyje go nieuprawniona osoba.
• Użytkownik otwiera e‑mail na jednym urządzeniu, a chce sesję na innym i myli się, gdy aplikacja otwiera się w „nieodpowiednim” miejscu.
• Wspólne urządzenie pozostaje zalogowane, więc kolejna osoba ma dostęp.
• Adres e‑mail jest wpisany błędnie i link trafia do kogoś innego.

Mały przykład: ktoś zamawia link na firmowym laptopie, potem sprawdza pocztę na prywatnym telefonie. Stuka link, telefon go loguje, a laptop wciąż pokazuje ekran logowania. Jeśli Twój przepływ tego nie wyjaśnia, pojawią się zgłoszenia do wsparcia.

Jeśli budujesz to w produkcie tworzonym w AppMaster, traktuj etap wysyłki e‑maila jak działanie wrażliwe, a nie tylko wygodę. Jasne komunikaty, krótkotrwałe linki i prosta kontrola sesji sprawiają, że doświadczenie wydaje się bezpieczne.

Czy logowanie e‑mail bez hasła pasuje do twojego produktu?

Logowanie bez hasła za pomocą linków magicznych sprawdza się najlepiej, gdy celem jest szybki dostęp przy minimalnym tarciu, a nie maksymalna ochrona. To dobre rozwiązanie dla produktów, w których użytkownicy logują się rzadko i nie lubią resetów haseł, oraz tam, gdzie skrzynka e‑mail jest już dla nich „bazą”.

Prosty sposób decyzji: jeśli ktoś dostanie się do niewłaściwego konta, jakie jest najgorsze realistyczne szkody? Jeśli odpowiedź to „upiększenia lub da się naprawić”, linki magiczne mogą być dobrym domyślnym rozwiązaniem.

Dobrym dopasowaniem są często:

• Aplikacje o niskim lub średnim ryzyku (narzędzia wewnętrzne, panele administracyjne małych zespołów, portale klientów z ograniczonymi uprawnieniami)
• Produkty z rzadkimi użytkownikami, którzy nie lubią resetów haseł
• Doświadczenia „szybkiego wejścia”, jak wsparcie, onboarding czy zatwierdzenia
• Produkty wczesnego stadium, które chcą mieć mniej zgłoszeń do wsparcia

Bądź ostrożny lub unikaj linków magicznych jako jedynej metody logowania, gdy:

• Konta mają wysoką wartość (przelewy pieniędzy, duże salda, działania nieodwracalne)
• Przechowujesz regulowane lub wrażliwe dane (zdrowotne, prawne, szczegółowe dane finansowe)
• Użytkownicy często współdzielą skrzynki (wspólne skrzynki, konta recepcji)
• Twoja grupa docelowa może być szczególnie atakowana (kadra zarządzająca, administratorzy, role o wysokich uprawnieniach)

Jeśli produkt ma momenty wrażliwe, a nie koniecznie wrażliwe konta, użyj logowania e‑mailowego do wejścia, a następnie dodaj drugą warstwę lub podwyższony poziom weryfikacji przy ryzykownych akcjach. Na przykład wymagaj dodatkowego potwierdzenia przy zmianie danych wypłat, eksporcie danych czy dodawaniu nowego administratora.

Zdecyduj też, co e‑mail ma móc robić. „Tylko logowanie” jest bezpieczniejsze i łatwiejsze do przemyślenia. „Logowanie + odzyskiwanie konta” jest wygodne, ale oznacza, że każdy mający dostęp do e‑maila może przejąć konto. Jeśli wspierasz zmianę adresu e‑mail, traktuj to jako działanie wysokiego ryzyka.

Jeśli budujesz aplikację w platformie no‑code jak AppMaster, ta decyzja nadal jest istotna: UI może być proste, ale twoja polityka dotycząca działań wrażliwych i odzyskiwania powinna być od razu jasno określona.

Podstawowy przepływ linka magicznego (i decyzje w nim zawarte)

Linki magiczne użytkownik postrzega jako proste, ale pod spodem kryje się wiele drobnych wyborów. Czysty przepływ utrzymuje ludzi w ruchu i zmniejsza liczbę zgłoszeń do wsparcia.

Co widzi użytkownik

Większość produktów stosuje ten sam schemat: użytkownik wpisuje e‑mail, otrzymuje wiadomość, klika link i ląduje zalogowany.

Częstym usprawnieniem jest krótki ekran potwierdzenia po otwarciu linku. Zamiast natychmiastowego logowania, pokaż krótki ekran typu „Potwierdź logowanie do Acme” z jednym przyciskiem. Pomaga to, gdy ktoś otworzy link na niewłaściwym urządzeniu lub gdy e‑mail został podglądnięty przez narzędzie podglądu.

Na urządzeniach mobilnych zdecyduj, co oznacza „stuknij link”. Jeśli masz natywną aplikację, najlepsze doświadczenie to zwykle: stuknij link -> otwórz aplikację -> dokończ logowanie. Jeśli aplikacja nie jest zainstalowana, pokaż fallback do webu mobilnego i później opcję „Otwórz w aplikacji”.

Decyzje, które musisz podjąć

Zanim zbudujesz logowanie bez hasła, ustal te reguły, aby doświadczenie było przewidywalne:

• Gdzie link się otwiera: w przeglądarce wbudowanej w aplikację, w systemowej przeglądarce czy bezpośrednio w natywnej aplikacji (deep link).
• Czy logowanie jest automatyczne, czy wymaga końcowego ekranu potwierdzającego.
• Co robisz, jeśli użytkownik jest już zalogowany, gdy stuknie link.
• Co się dzieje, gdy e‑mail zostanie zmieniony w trakcie przepływu lub użytkownik wpisze inny adres przy kolejnym żądaniu.
• Jak wygląda „sukces”: czy ląduje się na ostatniej stronie, na domyślnym ekranie głównym, czy na stronie, która wymagała logowania.

Już zalogowany użytkownik to łatwe do przeoczenia. Jeśli zalogowany użytkownik stuknie nowy link, możesz (a) zostawić go w tym samym koncie i pokazać „Jesteś już zalogowany”, lub (b) traktować to jako przełączenie konta i poprosić o potwierdzenie. W aplikacjach tworzonych w AppMaster (np. portale klientów czy narzędzia wewnętrzne) opcja (a) zazwyczaj jest bezpieczniejsza, chyba że przełączanie kont jest faktyczną funkcją.

Zasady wygasania: krótkie, by było bezpiecznie; wystarczająco długie, by zadziałało

Link magiczny pozostaje „bezhasłowy” tylko jeśli działa bez wysiłku. Wygasanie to część, która może cicho złamać to obietnicę. Zbyt krótko — użytkownicy trafiają na wygasłe linki; zbyt długo — przekazany lub ujawniony e‑mail staje się większym ryzykiem.

Praktyczny punkt startowy dla logowania bez hasła to okno wygasania między 10 a 30 minutami. Krótsze okna (3–10 minut) pasują do działań wyższego ryzyka, jak logowanie do panelu admina czy zatwierdzanie płatności. Dłuższe (30–60 minut) mogą działać w aplikacjach niskiego ryzyka, ale tylko jeśli masz silną kontrolę sesji i dobre zarządzanie urządzeniami.

Wyraźnie komunikuj czas wygasania w e‑mailu i na ekranie „Sprawdź swój e‑mail”. Nie chowaj tego w małym druku. Użyj prostego sformułowania, np. „Ten link wygasa za 15 minut.” Jeśli możesz, pokaż odliczanie na ekranie oczekiwania, ale nie polegaj na zegarze urządzenia użytkownika.

Opóźnienia w dostawie i różnice czasowe są powszechne. Niektórzy dostawcy przetrzymują wiadomości kilka minut, a niektórzy użytkownicy otwierają e‑mail na innym urządzeniu niż to, które żądało linku. Kilka reguł pomaga uniknąć zamieszania:

• Opieraj wygasanie na czasie serwera, nie na zegarze użytkownika.
• Jeśli link zbliża się do wygaśnięcia, pokaż jasny komunikat typu „Link wygasł. Poproś o nowy.”
• Jeśli link jest nadal ważny, ale już użyty, powiedz to wprost (i zaoferuj szybki następny krok).

Gdy link wygasł, najlepsze doświadczenie to jedno‑stukowe ponowne wysłanie ze strony docelowej. Trzymaj to bezpiecznie: pozwól na ponowne wysłanie dopiero po krótkim cooldownie i unikaj ujawniania, czy dany e‑mail istnieje w systemie. Strona może mówić „Jeśli ten e‑mail jest zarejestrowany, wyślemy nowy link.”

Mały szczegół, który zmniejsza liczbę zgłoszeń: pokaż dokładny adres e‑mail (częściowo zamaskowany) na ekranie oczekiwania oraz opcję „Zmień e‑mail”. W narzędziu no‑code jak AppMaster to zwykle kilka stanów UI, ale zapobiega wielu „Nie dostałem e‑maila” nieporozumieniom.

Jednorazowe użycie i reguły ponownego użycia (części, z którymi użytkownicy faktycznie mają do czynienia)

Dla większości produktów domyślnie stosuj jednorazowe linki magiczne. Chroni to użytkowników przed typowymi wpadkami, jak przekazywanie e‑maili, współdzielone skrzynki czy ktoś otwierający starą wiadomość tygodniami później. Upraszcza też wsparcie: jeśli link został użyty, to koniec jego żywotności.

Kluczowe jest ustalenie, co w praktyce oznacza „użyty”. Ludzie klikają dwa razy, otwierają na złym urządzeniu lub używają podglądu wiadomości. Twoje reguły powinny być bezpieczne, ale też sprawiedliwe.

Co powinno się stać, gdy ten sam link zostanie otworzony dwa razy?

Dobry punkt wyjścia: pierwszy udany login zużywa token, a każde późniejsze otwarcie pokazuje jasny komunikat typu „Ten link był już użyty. Poproś o nowy.” Unikaj niejasnych błędów. Jeśli chcesz zmniejszyć frustrację, możesz zaoferować krótki bufor przed zużyciem, na przykład: oznacz token jako użyty dopiero po utworzeniu sesji.

Oto przyjazne dla użytkownika wzorce, które pozostają bezpieczne:

• Jeśli link zostanie ponownie otwarty na tym samym urządzeniu i użytkownik jest już zalogowany, po prostu przenieś go do aplikacji (bez komunikatów).
• Jeśli link zostanie ponownie otwarty, ale aktywna sesja nie istnieje, pokaż „Użyty lub wygasły” i jeden przycisk do wysłania nowego linku.
• Jeśli link zostanie otwarty na innym urządzeniu po jego użyciu, traktuj go jako nieważny i poproś o świeży link.

Jeśli użytkownicy proszą o wiele linków, czy starsze wygasają?

Zdecyduj o tym wcześniej i bądź konsekwentny. Najbezpieczniejszy domyślny wybór: każde nowe żądanie unieważnia wszystkie poprzednie oczekujące linki. Ogranicza to szkody, jeśli ktoś później uzyska dostęp do skrzynki.

Jeśli pozwalasz na jednoczesną ważność wielu linków, musisz wzmocnić ochronę (krótkie wygasanie, ścisłe jednorazowe użycie i jasne kontrole urządzeń/sesji). W przeciwnym razie logowanie bez hasła może cicho zmienić się w długotrwałe klucze dostępu siedzące w e‑mailu.

Unikaj wielokrotnego użycia tych samych linków. Nawet jeśli wydaje się wygodne, uczy użytkowników traktować e‑mail jako stały klucz i utrudnia ograniczenie przejęcia konta.

Jeśli budujesz przepływ w narzędziu no‑code jak AppMaster, zapisz te reguły jako proste stany (ważny, użyty, wygasły, zastąpiony), aby komunikaty UI odpowiadały temu, co backend faktycznie egzekwuje.

Szczegóły UX, które zmniejszają zamieszanie i liczbę zgłoszeń do wsparcia

Większość zgłoszeń dotyczących linków magicznych to nie błędy bezpieczeństwa. To: „Nie dostałem maila”, „Kliknąłem i nic się nie stało” albo „Czy to phishing?”. Dobre UX zapobiega wszystkim trzem.

Po wysłaniu e‑maila pokaż dedykowany ekran „Sprawdź swój e‑mail” zamiast małego powiadomienia. Bądź spokojny i konkretny: powiedz, na jaki adres wysłaliśmy, co zrobić dalej i co spróbować, jeśli wiadomość nie dotrze.

Silny ekran sprawdzania poczty zwykle zawiera:

• Dokładny użyty adres e‑mail z wyraźną opcją „Zmień e‑mail”
• Przycisk ponownego wysłania z krótkim odliczaniem (żeby użytkownicy nie klikali spamowo)
• Notatkę o typowym czasie dostawy (np. „Zazwyczaj w ciągu 1 minuty”)
• Delikatne przypomnienie o sprawdzeniu spamu, zakładek Promocje i filtrów firmowych
• Krótką informację o bezpieczeństwie: „Nie przekazuj tego linku”

Zaufanie buduje się w samej wiadomości. Używaj spójnej nazwy nadawcy i tematu, a treść trzymaj przewidywalną. Dodaj jedną lub dwie wskazówki, które pomogą użytkownikowi uwierzyć, że to legalne, np. „Żądane z Chrome na Windows” lub „Żądane o 15:42”. Unikaj przerażającego języka. Proste sformułowanie wystarczy: „Ten link loguje do konta. Jeśli go nie żądałeś, możesz zignorować tę wiadomość.”

Planuj też najczęstszą awarię: opóźniony albo zablokowany e‑mail. Twoje UI nie powinno kończyć się w martwym punkcie. Jeśli link może chwilę zająć, powiedz użytkownikowi, co robić w międzyczasie i zaproponuj przyjazny fallback.

Praktyczny fallback to dołączenie krótkiego jednorazowego kodu w tej samej wiadomości co link. Wtedy ekran „Sprawdź swój e‑mail” może zaproponować „Wpisz kod zamiast linku” dla przypadków, gdy link otwierany jest na złym urządzeniu lub blokowany przez systemy bezpieczeństwa.

Mały, ale ważny detal: gdy użytkownik kliknie stary lub już użyty link, pokaż pomocny komunikat i jeden jasny następny krok, np. „Wyślij nowy link”, zamiast ogólnego błędu.

Podstawy bezpieczeństwa w tle (bez ciężkiego gadania o kryptografii)

Link magiczny to token tymczasowo dający dostęp do konta: traktuj go jak tymczasowy klucz — musi być trudny do odgadnięcia, krótkotrwały i używany tylko w zamierzony sposób.

Zacznij od nieprzewidywalności. Generuj długie, losowe tokeny (nie bazujące na e‑mailu, czasie czy inkrementalnych ID). Przechowuj możliwie jak najmniej. Powszechny wzorzec to przechowywanie zahashowanej wersji tokenu (gdy baza ucieknie, surowy link nie będzie mógł być ponownie użyty) plus minimalna ilość metadanych potrzebnych do jego weryfikacji.

Powiązanie tokenu z kontekstem może zapobiec prostemu przekazywaniu. Nie zawsze chcesz ścisłego powiązania (użytkownicy zmieniają urządzenia), ale możesz dodać lekkie kontrole, które wykryją ewidentne nadużycia. Przykłady: powiąż token z e‑mailem, dla którego został żądany, i opcjonalnie z przybliżonym fingerprintem, jak rodzina user agenta czy pierwszy obserwowany zakres IP. Jeśli kontekst nie pasuje, poproś o świeży link zamiast całkowitego zablokowania.

Ograniczanie liczby żądań ma większe znaczenie niż finezyjne obliczenia. Bez niego atakujący mogą spamować formularz logowania, denerwować użytkowników i sprawdzać, czy e‑maile istnieją.

• Ograniczaj żądania na e‑mail i na IP (w tym ponowne wysyłanie)
• Dodaj krótki cooldown między e‑mailami (np. 30–60 sekund)
• Pokaż tę samą wiadomość niezależnie od tego, czy e‑mail istnieje
• Alertuj przy nagłych skokach (wiele e‑maili do wielu adresów)

Na koniec: loguj to, czego naprawdę potrzebujesz, gdy użytkownik mówi „Nie robiłem tego”. Rejestruj zdarzenia typu: żądanie linku, wysłanie e‑maila, otwarcie linku, token zaakceptowany/odrzucony (i dlaczego) oraz utworzenie sesji. Zapisuj znacznik czasu, IP i user agenta. W narzędziu zbudowanym w AppMaster te zdarzenia mogą być rejestrowane jako część procesu logowania, dzięki czemu wsparcie i bezpieczeństwo mają czytelny ślad bez grzebania w serwerowych logach.

Zarządzanie urządzeniami i sesjami w sposób zrozumiały dla użytkowników

Linki magiczne eliminują hasła, ale użytkownicy myślą w kategoriach urządzeń: „Zalogowałem się na telefonie” lub „Użyłem współdzielonego laptopa”. Jeśli nie dasz im prostego sposobu na przeglądanie i kończenie sesji, zgłoszeń do wsparcia szybko przybędzie.

Zacznij od jednej decyzji: ile aktywnych sesji może mieć jedno konto jednocześnie. Dla większości produktów konsumenckich wiele sesji jest OK (telefon + laptop). Dla narzędzi wrażliwych (panel admina, finanse, operacje wewnętrzne) możesz ograniczyć to lub żądać świeżego linku, gdy pojawia się nowe urządzenie.

Mała strona „Urządzenia” lub „Aktywne sesje” ułatwia zrozumienie. Trzymaj to proste i lekko niedokładne zamiast przesadnej precyzji. Dobry wiersz zwykle zawiera:

• Nazwę urządzenia (albo przeglądarkę i system, jeśli nie możesz wykryć modelu)
• Przybliżoną lokalizację (miasto lub region, nie pełny adres)
• Czas ostatniej aktywności
• Czas pierwszego wykrycia
• Krótką etykietę typu „To urządzenie” dla bieżącej sesji

Dalej daj dwie jasne akcje. „Wyloguj” powinno zakończyć tylko tę sesję. „Wyloguj ze wszystkich urządzeń” powinno zakończyć wszystko, łącznie z bieżącym urządzeniem, i wymusić nowe linki wszędzie.

Pomiędzy tymi akcjami określ, co się dzieje, gdy urządzenie zostanie zgubione lub współdzielone. Najbezpieczniejszy domyślny wybór: wylogowanie unieważnia wszystkie istniejące sesje i wszystkie nieużyte linki magiczne, które już zostały wysłane. Użytkownicy nie potrzebują szczegółów; potrzebują gwarancji, że stary dostęp zniknął.

Prosty zestaw zachowań, który rzadko zaskakuje użytkowników:

• Nowe logowanie przez link magiczny tworzy nową sesję
• Każda sesja ma timeout bezczynności (np. dni) i maksymalny wiek (np. tygodnie)
• Zmiana e‑maila powoduje „wyloguj ze wszystkich urządzeń”
• „Wyloguj ze wszystkich urządzeń” również unieważnia oczekujące linki

Jeśli budujesz to w AppMaster, możesz zamodelować sesje w Data Designer, pokazać je w prostym UI web/mobile i dodać przyciskowe akcje w Business Process. Użytkownicy dostają znany widok „aktywne sesje” bez konieczności zamieniania tego w podręcznik bezpieczeństwa.

Zagrożenia i przypadki brzegowe: przekazywanie, skrzynki współdzielone i literówki

Linki magiczne wydają się proste, ale e‑mail bywa chaotyczny. Ludzie przekazują wiadomości, współdzielą skrzynki i robią literówki. Jeśli zaprojektujesz system tylko na idealny przypadek, skończysz z mylącymi blokadami i trudnymi zgłoszeniami do wsparcia.

Przekazywanie to największe zaskoczenie. Logowanie bez hasła powinno zakładać, że link może być otwarty przez kogoś innego, na innym urządzeniu, minuty lub godziny później. Najbezpieczniejsza podstawa to jednorazowe użycie plus jasny komunikat „ten link był już użyty” z przyciskiem do odświeżenia. Jeśli chcesz dodatkowej ochrony, pokaż lekki ekran potwierdzenia po kliknięciu na nowym urządzeniu (np. „To Ty?” z szybką opcją anulowania sesji).

Skrzynki współdzielone wymagają decyzji produktowej, nie tylko łatki technicznej. Jeśli wiele osób ma dostęp do tej samej poczty (jak support@ lub sales@), linki magiczne domyślnie stają się współdzielonym dostępem. Rozważ wymóg dodatkowego kroku dla kont zespołowych (np. zaproszenie na osobisty e‑mail) lub wyraźne zaznaczenie w UI, że dostęp do e‑maila równa się dostępowi do konta.

Literówki tworzą „duchowe konta” i kłopotliwe kwestie prywatności. Unikaj cichego tworzenia nowych kont przy pierwszym logowaniu, chyba że produkt wyraźnie tego potrzebuje. Bezpieczniejsze podejście to potwierdzenie intencji w aplikacji przed onboardingiem i neutralna odpowiedź e‑mail (ta sama, niezależnie od istnienia konta).

Aliasowanie ma znaczenie. Zdecyduj, jak traktujesz plus‑adresowanie (name+tag@) i aliasy u dostawców:

• Traktuj e‑maile jako dokładne ciągi (prościej, mniej niespodzianek)
• Albo normalizuj powszechne wzorce (mniej zduplikowanych kont, ale ryzyko łączenia użytkowników, którzy tego nie oczekiwali)

Wsparcie to miejsce, gdzie sprawy mogą szybko pójść źle. Nie proś użytkowników o przesyłanie wiadomości, wklejanie tokenów ani zrzuty ekranu linków. Zamiast tego oferuj proste akcje w aplikacji: „wyślij nowy link”, „wyloguj inne urządzenia” i „zgłoś, że to nie ja”, aby wsparcie mogło pomóc bez dostępu do wrażliwych danych.

Szybka lista kontrolna przed wdrożeniem

Zanim uruchomisz logowanie bez hasła za pomocą linków magicznych, ustal, co ma się dziać w realnym świecie: wolna dostawa e‑maili, ludzie klikający dwa razy i przełączający się między telefonem a laptopem.

Zacznij od reguł kontrolujących ryzyko i obciążenie wsparcia. Jeśli te rzeczy zawiodą, UI cię nie uratuje.

• Ustal jasne okno wygasania (często 10–20 minut) i pokaż je w e‑mailu i na ekranie „Sprawdź swój e‑mail”.
• Domyślnie stosuj jednorazowe linki i określ, co oznacza „użyty” (po kliknięciu, po utworzeniu sesji lub po pierwszym otwarciu).
• Dodaj limity ponownego wysyłania i pacing (np. krótki cooldown) oraz przyjazny komunikat wyjaśniający, dlaczego nie można spamować „wyślij ponownie”.
• Ogranicz aktywne sesje na użytkownika tam, gdzie to sensowne, i ustal, co się dzieje, gdy limit zostanie osiągnięty (zachowaj najnowsze, najstarsze lub poproś o decyzję).
• Obsługuj wielokrotne kliknięcia i stare linki przewidywalnie: jeśli link wygasł lub był użyty, pokaż prostą stronę z jedną główną akcją („Wyślij nowy link”).

Następnie sprawdź części widoczne dla użytkownika. Większość skarg wynika z niejasnych e‑maili i mylącego zachowania mobilnego.

• Treść e‑maila: rozpoznawalna nazwa nadawcy, jasny temat, prosty język i krótka linia „Nie prosiłeś o to?”, która wyjaśnia, co zrobić.
• Zachowanie mobilne: potwierdź, co się dzieje, jeśli użytkownik otworzy e‑mail na jednym urządzeniu, a chce zalogować się na innym, i czy wspierasz deep linki do aplikacji.
• Wielokrotne kliknięcia: jeśli użytkownik stuknie dwa razy, unikaj alarmujących błędów; powiedz, że jest już zalogowany lub że link nie jest już ważny.
• Zarządzanie urządzeniami: zapewnij prostą listę urządzeń, opcję „wyloguj to urządzenie” i podstawowe notatki (czas, urządzenie, lokalizacja jeśli dostępna).
• Odzyskiwanie: miej plan na „Nie mam dostępu do mojej poczty” (przepływ wsparcia, alternatywna weryfikacja lub bezpieczny proces zmiany konta).

Jeśli budujesz to w AppMaster, odwzoruj każdy punkt z listy kontrolnej na konkretny ekran i regułę biznesową w logice, aby zachowanie było spójne na webie i mobilnie.

Realistyczny przykład: logowanie na nowym urządzeniu, wygasły link i czyszczenie

Maya pracuje w wsparciu. W poniedziałek rano otwiera portal klienta na nowym laptopie. Wpisuje służbowy e‑mail i klika „Wyślij link do logowania”. E‑mail przychodzi z linkiem wygasającym za 10 minut.

Kliknięcie otwiera przeglądarkę i ląduje w portalu. W tle link zostaje przyjęty raz, a następnie oznaczony jako użyty. Portal tworzy nową sesję „Maya — Laptop Chrome” i utrzymuje ją przez 14 dni, chyba że się wyloguje.

Później tego dnia Maya próbuje zalogować się z telefonu. Ponownie używa porannego e‑maila i klika ten sam link. Aplikacja pokazuje jasny komunikat: „Ten link był już użyty. Poproś o nowy.” Prosi o kolejny link, ale się rozprasza. Po piętnastu minutach klika i widzi: „Ten link wygasł. Wyślij świeży.” Prosi ponownie, klika natychmiast i sesja telefonu zostaje utworzona jako „Maya — iPhone Safari”.

W piątek Maya pomaga współpracownikowi na współdzielonym służbowym laptopie. Loguje się, kończy zadanie, potem przechodzi do „Urządzenia” i klika „Wyloguj to urządzenie”. Przed odejściem także usuwa sesję współdzielonego laptopa z konta, aby nikt nie mógł już z niego korzystać.

Oto proste reguły, których przestrzegała aplikacja:

• Linki szybko wygasają (minuty), ale sesje mogą trwać dłużej (dni)
• Każdy link działa raz; użyte lub wygasłe linki nie są ponownie używalne
• Każde logowanie tworzy nazwaną sesję urządzenia, którą użytkownik może przeglądać
• Użytkownicy mogą wylogować pojedyncze urządzenie lub unieważnić wszystkie sesje, jeśli trzeba

Aby zbudować ten przepływ w AppMaster, zacznij od modułu uwierzytelniania i włącz logowanie e‑mailowe. Przechowuj sesje w bazie (użytkownik, nazwa urządzenia, czas utworzenia, czas ostatniego użycia). Użyj modułu wiadomości, by wysyłać e‑mail logowania, oraz krótkiego Business Process do walidacji stanu tokenu (niewykorzystany, niewygasły), a potem twórz lub cofnij sesje. Jeśli chcesz mieć logowanie bez hasła przy minimalnym kodowaniu, możesz stworzyć ekrany i logikę w edytorach wizualnych i spróbować od razu.