Beim Ändern der Domäne müssten Benutzer die neue Domäne autorisieren, lokale Anwendungseinstellungen würden verloren gehen, SSO-Benutzer könnten sich ohne zusätzliche Einstellungen nicht anmelden - all dies war nicht benutzerfreundlich, die Häufigkeit der Kennwortwiederherstellung würde zunehmen und einige Benutzer könnten dies nicht um die Anwendung sofort zu nutzen.
Um den Datenverkehrsverlust nach dem Ändern der Domäne zu minimieren, mussten autorisierte Benutzer von der alten auf die neue Domäne migriert werden:
- Unterstützen Sie Benutzer, die sich über die alte Domäne mit SSO-Anbietern authentifiziert haben.
- Übertragen Sie das Autorisierungstoken des Benutzers von der alten Domäne auf die neue.
- Übergeben Sie LocalStorage mit benutzerdefinierten Anwendungseinstellungen.
Datenübertragung und Verschlüsselung
Es wurde beschlossen, das Token mithilfe von get-Parametern zu übertragen, da auf der Site keine Speicher verwendet wurden, in denen das Token gespeichert und wiederverwendet werden kann. Es ist nicht sicher, das Token über den Parameter get an die Öffentlichkeit zu übergeben. Es muss vor dem Abfangen geschützt werden. Wir hatten zwei Verschlüsselungsmethoden: OpenSSL und Mcrypt. Mcrypt wurde lange Zeit nicht aktualisiert, es verschlüsselt Daten langsamer als OpenSSL und wir benötigen keine zusätzliche Last auf dem Server. Daher haben wir das Token mit OpenSSL verschlüsselt.
Der resultierende Hash könnte jedoch immer noch abgefangen und erneut verwendet werden. Um zu verhindern, dass das Token wiederverwendet wird, haben wir den Parameter "Verschlüsselungsdatum" hinzugefügt. Dadurch war der Hash 10 Sekunden lang gültig - diesmal war dies mit einem Spielraum ausreichend, um alle Vorgänge auszuführen. Wir haben außerdem alle 12 Stunden einen Ersatzverschlüsselungsschlüssel hinzugefügt. Der Schlüssel wurde in Vault gespeichert und zwischen Standorten synchronisiert.
Der resultierende Hash wurde als get-Parameter übergeben und unter Verwendung von url_encode für die sichere Übertragung über die URL weiterverarbeitet, da die Zeichen der Struktur der Adresse entkommen oder sie verderben könnten.
Hash-Struktur:
url_encode(OpenSSL({
'token': '',
'date': ' ',
'additional_values': ['param', 'param']
}))
Auf LocalStorage kann nur über JavaScript zugegriffen werden. Um dieses Problem zu lösen, wurden die postMessage-Schnittstelle und ein iframe ausgewählt, die es ermöglichten, domänenübergreifende Anforderungen sicher zu senden. Die Daten in LocalStorage wurden mit JSON.stringify () in Zeichenfolgen konvertiert und in die Domäne miro.com übertragen, wo sie zurückkonvertiert und in den LocalStorage der Domäne miro.com geschrieben wurden.
Arbeitsschema mit einer Beschreibung aller Schritte
Schema in einer bequemen Form zum Anzeigen .
Benutzer können auf zwei Arten in den Dienst einsteigen: über die alte Domain realtimeboard.com (z. B. über Lesezeichen) oder über die neue miro.com (z. B. durch Werbung).
Wenn der Benutzer zur alten Domain gegangen ist:
- Nach dem Öffnen einer beliebigen Seite von realtimeboard.com werden das Token, das Erstellungsdatum und zusätzliche Serviceinformationen des Benutzers verschlüsselt.
- miro.com/migration/?data={hash} hash Get . , . .
- miro.com , , , , .
- migrationToken, .
- LocalStorage migrationLocalstorage. , JS-, iFrame relatimeboard.com/localstorage/ postmessage , .
Wenn der Benutzer direkt zur neuen miro.com-Domäne gewechselt ist, wurde überprüft, ob der Benutzer die Token- und LocalStorage-Migration bestanden hat. Wenn der Benutzer die Migration bereits abgeschlossen hat, blieb er in der Domäne miro.com. Wenn nicht, fand eine Weiterleitung zu realtimeboard.com statt, um ein Token zu erhalten (dazu haben wir zwei Flags in Cookies gespeichert: MigrationToken und MigrationLocalstorage).
Dieses Schema funktionierte auch gut für SSO-Benutzer, die sich bei der alten Domain realtimeboard.com angemeldet haben. Es wurde eine Liste von Routen hinzugefügt, die ohne Migration des Tokens in die neue Domäne funktionierten. Sie enthielten eine Route für SSO, die wie gewohnt ausgeführt und je nach Arbeitsstatus nach / app / oder / login / umgeleitet wurde. Danach wurde der Token-Migrationsmechanismus erneut verbunden.
Ausgabe
Ich verbrachte einen Monat mit Recherche und Vorbereitung, einen weiteren Monat mit der Durchführung (parallel dazu war ich an anderen Projekten beteiligt). Dank dieser Lösung konnten wir autorisierte Benutzer von der alten Domäne auf die neue migrieren und Benutzer unterstützen, die SSO für die Autorisierung über die alte Domäne verwendet haben.