Lors du changement de domaine, les utilisateurs devraient autoriser sur le nouveau domaine, les paramètres de l'application locale seraient perdus, les utilisateurs SSO ne pourraient pas se connecter sans paramètres supplémentaires de leur part - tout cela n'était pas convivial, la fréquence de récupération du mot de passe augmenterait et certains utilisateurs ne pourraient pas utiliserait l'application immédiatement.
Pour minimiser la perte de trafic après avoir changé de domaine, il était nécessaire de migrer les utilisateurs autorisés de l'ancien domaine vers le nouveau:
- Prise en charge des utilisateurs qui se sont authentifiés à l'aide de fournisseurs SSO via l'ancien domaine.
- Transférez le jeton d'autorisation de l'utilisateur de l'ancien domaine vers le nouveau.
- Passez LocalStorage avec des paramètres d'application personnalisés.
Transmission et cryptage des données
Il a été décidé de transférer le jeton à l'aide des paramètres get, car le site n'utilisait pas de stockages dans lesquels le jeton pouvait être enregistré et réutilisé. Il n'est pas sûr de transmettre le jeton au public via le paramètre get, il doit être protégé contre l'interception. Nous avions deux méthodes de cryptage: OpenSSL et Mcrypt. Mcrypt n'a pas été mis à jour depuis longtemps, il crypte les données plus lentement que OpenSSL, et nous n'avons pas besoin d'une charge supplémentaire sur le serveur. Par conséquent, nous avons chiffré le jeton à l'aide d'OpenSSL.
Cependant, le hachage résultant peut toujours être intercepté et réutilisé. Pour empêcher la réutilisation du jeton, nous avons ajouté le paramètre «date de chiffrement», ainsi le hachage était valide pendant 10 secondes - cette fois était suffisant avec une marge pour effectuer toutes les opérations. Nous avons également ajouté une clé de chiffrement de remplacement toutes les 12 heures, la clé était stockée dans Vault et synchronisée entre les sites.
Le hachage résultant a été passé en tant que paramètre get et a également été traité à l'aide de url_encode pour une transmission sécurisée via l'URL, car les caractères pouvaient être échappés ou gâcher la structure de l'adresse.
Structure de hachage:
url_encode(OpenSSL({
'token': '',
'date': ' ',
'additional_values': ['param', 'param']
}))
LocalStorage est uniquement accessible via JavaScript. Pour résoudre ce problème, l'interface postMessage et un iframe ont été choisis, ce qui a permis d'envoyer en toute sécurité des requêtes interdomaines. Les données de LocalStorage ont été converties en chaînes à l'aide de JSON.stringify () et transférées vers le domaine miro.com, où elles ont été reconverties et écrites dans le domaine LocalStorage de miro.com.
Schéma de travail avec une description de toutes les étapes
Le diagramme est sous une forme facile à visualiser .
Les utilisateurs pouvaient accéder au service de deux manières: via l'ancien domaine realtimeboard.com (par exemple, à partir de signets) ou via le nouveau miro.com (par exemple, via la publicité).
Si l'utilisateur est passé à l'ancien domaine:
- Après avoir ouvert une page sur realtimeboard.com, le jeton de l'utilisateur, la date de création et les informations de service supplémentaires sont chiffrés.
- miro.com/migration/?data={hash} hash Get . , . .
- miro.com , , , , .
- migrationToken, .
- LocalStorage migrationLocalstorage. , JS-, iFrame relatimeboard.com/localstorage/ postmessage , .
Si l'utilisateur est allé directement au nouveau domaine miro.com, une vérification a été effectuée pour s'assurer que l'utilisateur a passé la migration du jeton et de LocalStorage. Si l'utilisateur a déjà terminé la migration, il est resté sur le domaine miro.com. Sinon, une redirection vers realtimeboard.com a eu lieu pour obtenir un jeton (pour cela, nous avons stocké deux indicateurs dans les cookies: migrationToken et migrationLocalstorage).
Ce schéma a également bien fonctionné pour les utilisateurs SSO qui se sont connectés à l'ancien domaine realtimeboard.com. Une liste de routes a été ajoutée qui fonctionnait sans migrer le jeton vers le nouveau domaine. Ils comprenaient une route pour l'authentification unique, qui a été effectuée comme d'habitude et redirigée vers / app / ou / login / en fonction de l'état de son travail, après quoi le mécanisme de migration des jetons a été à nouveau connecté.
Production
J'ai passé un mois sur la recherche et la préparation, un autre mois sur son exécution (en parallèle, j'étais engagé dans d'autres projets). Avec cette solution, nous avons pu migrer les utilisateurs autorisés de l'ancien domaine vers le nouveau et prendre en charge les utilisateurs qui utilisaient SSO pour s'authentifier via l'ancien domaine.