When changing the domain, users would have to authorize on the new domain, local application settings would be lost, SSO users would not be able to log in without additional settings on their part - all this was not User friendly, the frequency of password recovery would increase, and some users could not at all would use the application right away.
To minimize the loss of traffic after changing the domain, it was necessary to migrate authorized users from the old domain to the new one:
- Support users who authenticated using SSO providers through the old domain.
- Transfer the user's authorization token from the old domain to the new one.
- Transfer LocalStorage with user settings for the application.
Data transmission and encryption
It was decided to transfer the token using get-parameters, since the site did not use storages in which it would be possible to save the token and reuse it. It is unsafe to pass the token to the public via the get parameter, it must be protected from interception. We had two encryption methods: OpenSSL and Mcrypt. Mcrypt has not been updated for a long time, it encrypts data more slowly compared to OpenSSL, and we do not need extra load on the server. Therefore, we encrypted the token using OpenSSL.
However, the resulting hash could still be intercepted and used again. In order to prevent the token from being reused, we added the "encryption date" parameter, thereby the hash was valid for 10 seconds - this time was enough with a margin to perform all operations. We also added a replacement encryption key every 12 hours, the key was stored in Vault and was synchronized between sites.
The resulting hash was passed as a get-parameter and was additionally processed using url_encode for secure transmission through the URL, since characters could be escaped or spoil the structure of the address.
Hash Structure:
url_encode(OpenSSL({
'token': '',
'date': ' ',
'additional_values': ['param', 'param']
}))
LocalStorage is only accessible via JavaScript. To solve this problem, the postMessage and iframe interface were chosen, which allowed us to safely send cross-domain requests. The data in LocalStorage was converted to strings using JSON.stringify () and transferred to the miro.com domain, where it was converted back and written to the LocalStorage of the miro.com domain.
Scheme of work with a description of all steps
The diagram is in an easy-to-view form .
Users could get into the service in two ways: through the old domain realtimeboard.com (for example, from bookmarks) or through the new miro.com (for example, through advertising).
If the user went to the old domain:
- After opening any page of realtimeboard.com, the encryption of the user's token, creation date and additional service information is performed.
- miro.com/migration/?data={hash} hash Get . , . .
- miro.com , , , , .
- migrationToken, .
- LocalStorage migrationLocalstorage. , JS-, iFrame relatimeboard.com/localstorage/ postmessage , .
If the user went directly to the new miro.com domain, a check was performed to ensure that the user passed the token and LocalStorage migration. If the user has already completed the migration, then he remained on the miro.com domain. If not, a redirect to realtimeboard.com took place to get a token (for this we stored two flags in cookies: migrationToken and migrationLocalstorage).
This scheme also worked well for SSO users who logged in to the old domain realtimeboard.com. A list of routes was added that worked without migrating the token to the new domain. They included a route for SSO, which was performed as usual and redirected to / app / or / login / depending on the state of its work, after which the token migration mechanism was connected again.
Output
I spent a month on research and preparation, another month on a run-in (at the same time was engaged in other projects). Thanks to this solution, we were able to migrate authorized users from the old domain to the new one and support users who used SSO for authorization through the old domain.