Ogólne wytyczne dotyczące migracji istniejącej bazy danych użytkowników do Logto
Ten artykuł przedstawia, jak wykorzystać istniejące narzędzia do migracji poprzednich danych użytkowników do Logto, w sytuacji, gdy Logto nie dostarczył jeszcze usług migracji danych.
Darcy YeDeveloper
Przestań tracić tygodnie na uwierzytelnianie użytkowników
Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.
Logto nie ma jeszcze zestawu narzędzi do migracji danych, ale udostępniliśmy podstawowe możliwości zarządzania API. To nie przeszkodzi użytkownikom w przeprowadzeniu migracji istniejących baz danych użytkowników przez napisanie skryptów.
Z uwagi na pewne potrzeby otrzymane od użytkowników społeczności, a także na fakt, że obecnie nie mamy dokumentacji wyjaśniającej konkretne kroki migracji bazy danych użytkowników, przedstawiamy w tym artykule poprawne wprowadzenie, które pomoże użytkownikom znaleźć konkretne pomysły i zaoszczędzić czas na czytanie kodu i dokumentacji Logto.
Krok 1: Zrozumienie podstawowej struktury danych użytkownika Logto i przypadku użycia#
Logto korzysta z bazy danych PostgreSQL ". Oprócz różnych zalet wydajności, ważnym powodem jest to, że obsługuje niestandardowy typ danych JSON/JSONB i pozwala na budowanie indeksów na wewnętrznych wartościach danych typu JSON, równoważąc wydajność bazy danych i rozszerzalność.
Aby zrozumieć strukturę danych użytkownika Logto, proszę zobacz odniesienie do użytkownika , aby zrozumieć wszystkie szczegóły. Tutaj skupiamy się na opisie tych aspektów, w których Logto może różnić się od innych usług tożsamości.
Jest to losowo generowany unikalny identyfikator wewnętrzny dla użytkowników Logto. Użytkownicy nie są świadomi id podczas korzystania z usług opartych na Logto.
Inżynierowie zaznajomieni z bazami danych nie powinni uważać tego za dziwne. Nawet najprostsze systemy tożsamości będą miały id do unikalnego identyfikowania użytkowników, chociaż ich formy często się różnią. Niektóre usługi tożsamości mogą korzystać z nazwy użytkownika, aby unikalnie identyfikować użytkowników.
Tu użytkownik, główny e-mail, główny telefon różni się znacznie od innych systemów tożsamości - mogą one wszystkie służyć jako unikalne identyfikatory dostrzegalne przez użytkowników końcowych.
W wielu innych systemach tożsamości, korzysta się z nazwy użytkownika do identyfikacji (nazwy użytkowników nie mogą być duplikowane między kontami), co jest łatwe do zrozumienia.
Ale w Logto, główny e-mail/telefon są również używane do odróżniania użytkowników. To znaczy, że jeśli użytkownik A już ma główny e-mail [email protected], to inny użytkownik B nie może dodać tego adresu e-mail jako swojego głównego e-maila. Podobnie działa główny telefon.
Niektóre inne systemy tożsamości pozwalają na rejestrację wielu kont z różnymi nazwami użytkowników, ale związanie tego samego e-maila/telefonu, co nie jest dozwolone w Logto (e-maile/telefony mogą być dodane do customData Logto). Jest to związane z tym, że główny e-mail/telefon w Logto może być używany do logowania bez hasła.
Logto definiuje to pole identities jako typ JSON, jego definicja typu:
W ostatnich latach, aby ułatwić pozyskiwanie nowych użytkowników, systemy tożsamości pozwalają użytkownikom na szybkie logowanie za pomocą niektórych istniejących kont społecznościowych z dużą bazą użytkowników, takich jak google / facebook itp.
W poniższym przykładzie pole identities przechowuje informacje o logowaniu społecznościowym:
Gdzie facebook i github są nazwami dostawców społecznościowych, userId to id konta społecznościowego użytkownika używanego do logowania. details zawierają również inne informacje, które użytkownik autoryzował dostawcę społecznościowy do wyświetlania, które będą dodawane do profilu użytkownika Logto w konkretnych momentach.
Jeśli poprzednia baza danych zawiera nazwę (np. facebook, google) i id dostawcy społecznościowego używanego przez użytkownika (patrz userId w poprzednim przykładzie), to użytkownik Logto może zalogować się bezpośrednio tym samym kontem społecznościowym.
To pole może przechowywać dowolne informacje związane z użytkownikiem, takie jak wymienione powyżej e-maile/telefony, które nie mogą być używane do logowania bez hasła (mogą być używane do odbierania powiadomień lub do innych funkcji związanych z biznesem) itp.
Pozostałe pola są stosunkowo łatwe do zrozumienia (z wyjątkiem passwordEncrypted i passwordEncryptionMethod, które zostaną wyjaśnione później), proszę przeczytać dokumentację samodzielnie.
W przypadku dużej migracji bazy danych, pisanie skryptów migracyjnych jest najczęstszym podejściem. Przedstawimy prosty przykład, który pomoże zrozumieć, jak pisać skrypty migracyjne, aby spełniać różne potrzeby.
Należy zauważyć, że podczas pisania skryptów migracyjnych, pomijamy proces odzyskiwania oryginalnych danych, ponieważ jest wiele sposobów na uzyskanie danych, takich jak eksportowanie z bazy danych do plików, a następnie odczytywanie tych plików, lub pobieranie za pomocą API. Te elementy nie są punktem centralnym skryptu migracji, dlatego nie omawiamy ich szczegółowo tutaj.
Kiedy widzisz tenant_id w skrypcie migracji, może ci się to wydać dziwne. Logto opiera się na architekturze wieloklientowej. Dla użytkowników Logto OSS (open source Logto), wystarczy ustawić tenant_id użytkownika na default.
Dla użytkowników samodzielnie hostowanych Logto OSS, połączenie z bazą danych jest łatwe do uzyskania. Jednak dla użytkowników chmury Logto, ze względu na względy bezpieczeństwa, obecnie nie możemy dostarczyć użytkownikom uprawnień do połączenia z bazą danych. Użytkownicy muszą skorzystać z API Docs i użyć User related APIs do migracji użytkowników. Rozumiemy, że ta metoda nie jest odpowiednia dla dużej migracji danych użytkowników, ale może obsłużyć migrację ograniczonej liczby użytkowników na tym etapie.
Krok 3: Wyzwanie migracji hasła hashowanego i potencjalne obejście#
W naszym poprzednim blogu, rozmawialiśmy o niektórych środkach do zapobiegania atakom na hasła. Jedną z rzeczy, które dostawcy infrastruktury tożsamości mogą zrobić, jest nie przechowywanie haseł w postaci jawnej, ale zapisywanie haseł hashowanych.
Kolejny wpis na blogu tłumaczył hashe haseł, gdzie stwierdziliśmy, że wartości hash są nieodwracalne.
Drugi wpis na blogu porównał też ewolucję niektórych algorytmów hashowania. Sam Logto używa wspomnianego w artykule algorytmu Argon2i i na razie nie obsługuje innych algorytmów hashujących. Oznacza to, że hashe haseł starej bazy danych użytkowników, które używały innych algorytmów hashowania, nie mogą być bezpośrednio przeniesione do bazy danych Logto.
Nawet jeśli Logto obsługuje inne powszechnie używane algorytmy hashowania oprócz Argon2i, nadal byłoby trudno bezpośrednio migrować stare dane z powodu elastyczności soli podczas stosowania algorytmów hashowania.
Oprócz obsługi innych algorytmów hashowania w przyszłości, Logto prawdopodobnie będzie również zapewniał niestandardowe metody obliczania soli, aby dostosować się do różnych sytuacji.
Przed tym można korzystać z konfiguracji doświadczenia logowania Logto sign-in experience configuration, aby pozwolić użytkownikom na logowanie przez inne sposoby (takie jak e-mail + kod weryfikacyjny) i wypełnienie nowego hasła (które będzie używać algorytmu hashowania Argon2i) przed wejściem do aplikacji. Następnie nowe hasło można używać do logowania później.
Należy zauważyć, że jeśli oryginalne dane użytkownika obsługują tylko logowanie za pomocą hasła, wspomniane wyżej obejście nie będzie działać w tym scenariuszu. Jest to związane z tym, że wspomniane wyżej obejście rozwiązuje rzeczywiście problem niezgodności hashu haseł, wykorzystując alternatywne metody logowania i wykorzystując mechanizm "wypełniania wymaganych informacji" w przepływie użytkownika końcowego Logto.
Więc jeśli tylko logowanie hasłem jest obsługiwane w oryginalnych danych użytkownika, obejście nie może rozwiązać tej sytuacji, ponieważ nie ma dostępnych opcji logowania alternatywnego.
Obejście wspomniane tutaj nie rozwiązuje naprawdę problemu migracji haseł hashowanych, ale dostarcza alternatywne rozwiązanie z perspektywy produktu Logto, aby uniknąć przeszkadzania użytkownikom w logowaniu do twojego produktu.
Krok 4: Stopniowe przejście do Logto i monitorowanie statusu#
Po wykonaniu powyższych kroków, użytkownicy końcowi mogą już logować się i korzystać z twojej usługi przez Logto.
Ponieważ zazwyczaj usługa nie jest przerywana podczas migracji, możliwe jest, że dane użytkownika zsynchronizowane z Logto nie są aktualne. Kiedy wykryje się takie nietypowe przypadki, należy wykonać synchronizację z starej bazy danych do Logto.
Po dłuższym okresie czasu (lub mogą być stosowane inne zdefiniowane metryki) bez wystąpienia niezgodnych danych, starą bazę danych można całkowicie porzucić.
W poście przedstawiliśmy kroki, przez które przechodzi idealna migracja bazy danych.
Jeśli napotkasz problemy, które nie zostały tutaj wspomniane, nie wahaj się dołączyć do naszej społeczności lub skontaktować się z nami o pomoc. Problemy, na które napotykasz, mogą również być napotykane przez innych i staną się kwestiami, które musimy rozważyć podczas projektowania narzędzi do migracji w przyszłości.
