Al cambiar el dominio, los usuarios tendrían que autorizar en el nuevo dominio, la configuración de la aplicación local se perdería, los usuarios de SSO no podrían iniciar sesión sin configuraciones adicionales de su parte; todo esto no era fácil de usar, la frecuencia de recuperación de contraseña aumentaría y algunos usuarios no podían para usar la aplicación de inmediato.
Para minimizar la pérdida de tráfico después de cambiar el dominio, fue necesario migrar los usuarios autorizados del dominio antiguo al nuevo:
- Admite usuarios que se autenticaron utilizando proveedores de SSO a través del dominio anterior.
- Transfiera el token de autorización de usuario del dominio antiguo al nuevo.
- Transfiera LocalStorage con la configuración del usuario para la aplicación.
Transferencia de datos y cifrado
Se decidió transferir el token usando parámetros get, ya que el sitio no usaba almacenamientos en los que sería posible guardar el token y reutilizarlo. No es seguro pasar el token al público a través del parámetro get, debe protegerse de la intercepción. Teníamos dos métodos de cifrado: OpenSSL y Mcrypt. Mcrypt no se ha actualizado durante mucho tiempo, encripta los datos más lentamente que OpenSSL y no necesitamos una carga adicional en el servidor. Por lo tanto, ciframos el token usando OpenSSL.
Sin embargo, el hash resultante aún podría ser interceptado y utilizado nuevamente. Para evitar que el token se reutilice, agregamos el parámetro "fecha de cifrado", por lo que el hash fue válido durante 10 segundos; esta vez fue suficiente con un margen para realizar todas las operaciones. También agregamos una clave de cifrado de reemplazo cada 12 horas, la clave se almacenó en Vault y se sincronizó entre sitios.
El hash resultante se pasó como parámetro get y se procesó adicionalmente usando url_encode para una transferencia segura a través de URL, ya que los caracteres podrían escapar o estropear la estructura de la dirección.
Estructura de hash:
url_encode(OpenSSL({
'token': '',
'date': ' ',
'additional_values': ['param', 'param']
}))
LocalStorage solo está disponible a través de JavaScript. Para resolver este problema, se eligió la interfaz postMessage y iframe, que permitió enviar solicitudes de dominio cruzado de forma segura. Los datos en LocalStorage se convirtieron en cadenas usando JSON.stringify () y se transfirieron al dominio miro.com, donde se volvieron a convertir y se escribieron en LocalStorage del dominio miro.com.
Esquema de trabajo con una descripción de todos los pasos.
El diagrama está en una forma fácil de ver .
Los usuarios pueden ingresar al servicio de dos maneras: a través del antiguo dominio realtimeboard.com (por ejemplo, desde marcadores) o a través del nuevo miro.com (por ejemplo, a través de publicidad).
Si el usuario fue al dominio anterior:
- Después de abrir cualquier página en realtimeboard.com, se cifran el token del usuario, la fecha de creación y la información adicional del servicio.
- miro.com/migration/?data={hash} hash Get . , . .
- miro.com , , , , .
- migrationToken, .
- LocalStorage migrationLocalstorage. , JS-, iFrame relatimeboard.com/localstorage/ postmessage , .
Si el usuario fue directamente al nuevo dominio miro.com, se verificó que el usuario pasó la migración del token y LocalStorage. Si el usuario ya ha completado la migración, permanecerá en el dominio miro.com. De lo contrario, se realizó una redirección a realtimeboard.com para obtener un token (para esto almacenamos dos banderas en cookies: MigrationToken y MigrationLocalstorage).
Este esquema funcionó igual de bien para los usuarios de SSO que iniciaron sesión en el antiguo dominio realtimeboard.com. Se agregó una lista de rutas que funcionaron sin migrar el token al nuevo dominio. Incluyeron una ruta para SSO, que se ejecutó como de costumbre y se redirigió a / app / o / login / dependiendo del estado de su trabajo, después de lo cual el mecanismo de migración de token se conectó nuevamente.
Salida
Pasé un mes en investigación y preparación, otro mes en ejecutarlo (en paralelo, participé en otros proyectos). Con esta solución, pudimos migrar usuarios autenticados del dominio antiguo al nuevo y admitir usuarios que usaban SSO para autenticarse a través del dominio antiguo.