Eine allgemeine Anleitung zur Migration Ihrer bestehenden Benutzerdatenbank zu Logto

Logto hat noch keine Reihe von Tools für die Datenmigration, aber wir haben grundlegende Fähigkeiten der Management-API geöffnet. Dies wird die Benutzer nicht daran hindern, die Migration von bestehenden Benutzerdatenbanken durch das Schreiben von Skripten zu vervollständigen.

Angesichts einiger Bedarfe, die wir von Community-Nutzern erhalten haben, und der Tatsache, dass wir zurzeit keine Dokumentation haben, die die spezifischen Schritte der Benutzerdatenbankmigration erklärt, machen wir eine geeignete Einführung in diesem Artikel, um den Benutzern zu helfen, spezifische Ideen zu finden und Zeit beim Lesen des Logto-Codes und der Dokumentation zu sparen.

Schritt 1: Verstehen Sie die grundlegende Benutzerdatenstruktur und den Anwendungsfall von Logto#

Logto verwendet PostgreSQL-Datenbank unter seiner Haube. Neben seinen verschiedenen Leistungsvorteilen ist ein wichtiger Grund, dass es den benutzerdefinierten JSON/JSONB-Datentyp unterstützt und die Indexierung auf interne Werte von JSON-getypten Daten erlaubt, die Datenbankleistung und Erweiterbarkeit ausgleicht.

Für die Benutzerdatenstruktur von Logto, verweisen Sie bitte auf Benutzerreferenz um alle Details zu verstehen. Hier konzentrieren wir uns auf die Beschreibung einiger Aspekte, in denen sich Logto von anderen Identitätsservices unterscheiden könnte.

id#

Dies ist ein zufällig generierter interner eindeutiger Identifier für Benutzer von Logto. Die Benutzer sind sich der id nicht bewusst, wenn sie Logto-basierte Dienste nutzen.

Ingenieure, die mit Datenbanken vertraut sind, sollten dies nicht seltsam finden. Selbst die rudimentärsten Identitätssysteme haben eine id, um Benutzer eindeutig zu identifizieren, obwohl ihre Formen oft unterschiedlich sind. Einige Identitätsservices können den Benutzernamen verwenden, um Benutzer eindeutig zu identifizieren.

username, primaryEmail, primaryPhone#

Hier, Benutzername, primäre E-Mail, primäres Telefon sind Punkte, in denen sich Logto stark von anderen Identitätssystemen unterscheidet - sie können alle als vom Endbenutzer wahrnehmbare eindeutige Identifier dienen.

In vielen anderen Identitätssystemen wird der Benutzername zur Identifikation verwendet (Benutzernamen können nicht zwischen Konten dupliziert werden), was leicht zu verstehen ist.

Aber bei Logto werden auch primäre E-Mail/Telefon zur Unterscheidung der Benutzer verwendet. Das heißt, wenn ein Benutzer A bereits die primäre E-Mail [email protected] hat, dann können andere Benutzer B diese E-Mail-Adresse nicht als ihre primäre E-Mail hinzufügen. Das primäre Telefon funktioniert ähnlich.

Einige andere Identitätssysteme erlauben die Registrierung mehrerer Konten mit unterschiedlichen Benutzernamen, aber binden die gleiche E-Mail/Telefon, was bei Logto nicht erlaubt ist (E-Mails/Telefone können zu Logto’s customData hinzugefügt werden). Das liegt daran, dass primäre E-Mail/Telefon in Logto genutzt werden können für passwortlosen Anmeldevorgang.

identities#

Logto definiert dieses identities Feld als JSON-Typ, seine Typendefinition:

In den letzten Jahren, um das Gewinnen von neuen Benutzern zu erleichtern, erlauben Identitätssysteme den Benutzern, sich schnell über einige bestehende soziale Konten mit einer großen Benutzerbasis anzumelden, wie google / facebook etc.

Im folgenden Beispiel speichert das identities Feld soziale Login-Informationen:

Wo facebook und github die Namen der sozialen Anbieter sind, userId ist die id des sozialen Benutzerkontos der Benutzer zur Anmeldung. Die details beinhalten auch noch einige andere Informationen, die der Benutzer dem sozialen Anbieter zur Anzeige autorisiert hat, die zu bestimmten Zeiten zum Benutzerprofil der Benutzer von Logto hinzugefügt werden.

Wenn die vorherige Datenbank den Namen (z.B. facebook, google) und die id des vom Benutzer genutzten sozialen Anbieters enthält (siehe userId im vorherigen Beispiel), dann kann der Logto-Benutzer sich direkt mit dem gleichen sozialen Konto anmelden.

customData#

Dieses Feld kann jegliche Benutzer-bezogene Information speichern, wie E-Mails/ Telefone, die oben erwähnt wurden, die nicht für passwortlosen Anmeldevorgang genutzt werden können (kannen genutzt werden, um Benachrichtigungen zu empfangen oder für andere Geschäftsbezogene Funktionen), etc.

Andere Felder sind relativ leicht zu verstehen (außer passwordEncrypted und passwordEncryptionMethod, was später erklärt wird), lesen Sie bitte die Dokumentation selbst.

Schritt 2: Schreiben von Datenbankmigrationsskripten#

Für groß angelegte Datenbankmigration ist das Schreiben von Migrationsskripten der gängigste Ansatz. Wir werden ein einfaches Beispiel geben, um zu verstehen, wie man Migrationsskripte schreibt, um unterschiedliche Bedürfnisse zu erfüllen.

Es sollte beachtet werden, dass wir beim Schreiben von Migrationsskripten den Prozess des Abrufens der Originaldaten überspringen, da es viele Wege gibt, Daten zu erhalten, wie z.B. Exportieren aus der Datenbank zu Dateien und dann das Lesen der Dateien, oder das Abrufen durch APIs. Diese sind nicht der Schwerpunkt des Migrationsskripts, daher werden wir sie hier nicht im Detail besprechen.

Wenn Sie tenant_id im Migrationsskript sehen, finden Sie es vielleicht seltsam. Logto basiert auf einer Multi-Tenant-Architektur. Für Benutzer von Open-Source Logto (Logto OSS) können Sie einfach die tenant_id des Benutzers auf default setzen.

Für selbst gehostete Benutzer von Logto OSS, ist die Datenbankverbindung einfach zu erhalten. Aber für Nutzer der Logto Cloud, aus Sicherheitsgründen, können wir zurzeit nicht die Berechtigung zur Datenbankverbindung an Nutzer geben. Benutzer müssen auf die API-Dokumentation verweisen und die Benutzer bezogenen APIs verwenden, um Benutzer zu migrieren. Wir verstehen, dass diese Methode nicht für die Migration von großen Mengen von Benutzerdaten geeignet ist, kann aber immer noch den Umzug einer begrenzten Anzahl von Benutzern in diesem Stadium handhaben.

Schritt 3: Migrationsherausforderung für gehashte Passwörter und potenzieller Workaround#

In unserem vorherigen Blog, sprachen wir über einige Maßnahmen, um Passwort-Attacken zu verhindern. Eine Sache, die Identitätsinfra-Anbieter tun können, ist, Passwörter nicht in Klartext zu speichern, sondern gehashte Passwörter zu speichern.

Ein weiterer Blog-Post erklärte Passwort-Hashes, worin wir feststellten, dass Hash-Werte nicht umkehrbar sind.

Der zweite Blog-Post verglich auch die Evolution einiger Hashing-Algorithmen. Logto selbst verwendet den im Artikel erwähnten Argon2i-Algorithmus und unterstützt zum jetzigen Zeitpunkt keine anderen Hash-Algorithmen. Das bedeutet, dass Passwort-Hashes von alten Benutzerdatenbanken, die andere Hashing-Algorithmen verwenden, nicht direkt in Logto's Datenbank migriert werden können.

Selbst wenn Logto in der Zukunft andere üblicherweise verwendete Hash-Algorithmen zusätzlich zu Argon2i unterstützt, wäre es immer noch schwierig, alte Daten direkt zu migrieren, wegen der Flexibilität von Salt beim Auftragen von Hashing-Algorithmen.

Zusätzlich zur Unterstützung anderer Hashing-Algorithmen in der Zukunft, ist Logto auch wahrscheinlich dazu in der Lage, benutzerdefinierte Salt-Berechnungsmethoden anzubieten, um sich an verschiedene Situationen anzupassen.

Bevor das passiert, können Sie die Anmeldeerfahrungskonfiguration von Logto nutzen, um den Benutzern zu erlauben, sich auf andere Weise anzumelden (wie E-Mail + Verifizierungscode) und ein neues Passwort auszufüllen (welches Argon2i-Hashing-Algorithmus verwenden wird) bevor sie in die App eintreten. Dann kann das neue Passwort später zum Anmelden verwendet werden.

Es sollte beachtet werden, dass wenn die originalen Benutzerdaten nur das Anmelden mit einem Passwort unterstützen, der oben erwähnte Workaround für dieses Szenario nicht funktionieren wird. Das liegt daran, dass der vorher erwähnte Workaround das Problem der Inkompatibilität des Passwort-Hashes eigentlich durch alternative Anmeldemethoden löst und sich des Mechanismus der "erforderlichen Informationsvervollständigung" in Logto's Endbenutzer-Flow bedient.

Also wenn im originalen Benutzerprofil nur Passwort-Login unterstützt wird, kann der Workaround diese Situation nicht lösen, da keine alternativen Login-Optionen zur Verfügung stehen.

Der hier erwähnte Workaround löst das Problem der Migration gehashter Passwörter nicht wirklich, bietet aber eine alternative Lösung aus der Sicht des Logto-Produkts, um zu verhindern, dass Benutzer daran gehindert werden, sich in Ihrem Produkt anzumelden.

Schritt 4: Schrittweiser Wechsel zu Logto und Statusüberwachung#

Nach Abschluss der obigen Schritte können Endbenutzer sich bereits über Logto in Ihren Service einloggen und ihn nutzen.

Da der Service in der Regel während der Migration nicht abgeschnitten wird, ist es möglich, dass die zu Logto synchronisierten Benutzerdaten nicht aktuell sind. Wenn solche ungewöhnlichen Fälle erkannt werden, muss eine Synchronisation von der alten Datenbank zu Logto durchgeführt werden.

Nach einer längeren Zeitspanne (oder andere definierte Metriken können angewendet werden) ohne das Auftreten von inkonsistenten Daten, kann die alte Datenbank komplett aufgegeben werden.

Fazit#

In dem Beitrag haben wir die Schritte vorgestellt, die eine ideale Datenbankmigration durchlaufen würde.

Wenn Sie auf Probleme stoßen, die oben nicht erwähnt wurden, zögern Sie nicht, sich unserer Community anzuschließen oder uns um Hilfe zu bitten. Die Probleme, denen Sie begegnen, können auch von anderen angetroffen werden und stellen Themen dar, die wir bei der Gestaltung von Migrationstools in der Zukunft berücksichtigen müssen.