Ao alterar o domínio, os usuários teriam que autorizar o novo domínio, as configurações de aplicativos locais seriam perdidas, os usuários de SSO não conseguiriam fazer login sem configurações adicionais da parte deles - tudo isso não era amigável, a frequência de recuperação de senha aumentaria e alguns usuários não podiam usaria o aplicativo imediatamente.
Para minimizar a perda de tráfego após alterar o domínio, era necessário migrar usuários autorizados do domínio antigo para o novo:
- Ofereça suporte a usuários autenticados usando provedores de SSO através do domínio antigo.
- Transfira o token de autorização do usuário do domínio antigo para o novo.
- Passe o LocalStorage com configurações personalizadas do aplicativo.
Transmissão e criptografia de dados
Decidiu-se transferir o token usando parâmetros-get, pois o site não usava armazenamentos nos quais seria possível salvar o token e reutilizá-lo. Não é seguro transmitir o token ao público por meio do parâmetro get, ele deve estar protegido contra interceptação. Tínhamos dois métodos de criptografia: OpenSSL e Mcrypt. O Mcrypt não é atualizado há muito tempo, criptografa os dados mais lentamente em comparação com o OpenSSL, e não precisamos de uma carga extra no servidor. Portanto, criptografamos o token usando o OpenSSL.
No entanto, o hash resultante ainda pode ser interceptado e usado novamente. Para impedir a reutilização do token, adicionamos o parâmetro "data de criptografia", portanto o hash era válido por 10 segundos - esse tempo foi suficiente com uma margem para executar todas as operações. Também adicionamos uma chave de criptografia de substituição a cada 12 horas, a chave foi armazenada no Vault e sincronizada entre sites.
O hash resultante foi passado como um parâmetro get e foi processado adicionalmente usando url_encode para transmissão segura através da URL, pois os caracteres podem ser escapados ou estragar a estrutura do endereço.
Estrutura de hash:
url_encode(OpenSSL({
'token': '',
'date': ' ',
'additional_values': ['param', 'param']
}))
LocalStorage só é acessível via JavaScript. Para resolver esse problema, a interface postMessage e um iframe foram escolhidos, o que possibilitou o envio seguro de solicitações entre domínios. Os dados no LocalStorage foram convertidos em seqüências de caracteres usando JSON.stringify () e transferidos para o domínio miro.com, onde foram convertidos novamente e gravados no domínio LocalStorage do miro.com.
Fluxo de trabalho com uma descrição de todas as etapas
O diagrama está em um formulário fácil de visualizar .
Os usuários podem entrar no serviço de duas maneiras: pelo antigo domínio realtimeboard.com (por exemplo, dos favoritos) ou pelo novo miro.com (por exemplo, pela publicidade).
Se o usuário foi para o domínio antigo:
- Após abrir qualquer página do realtimeboard.com, é realizada a criptografia do token do usuário, a data de criação e as informações adicionais de serviço.
- miro.com/migration/?data={hash} hash Get . , . .
- miro.com , , , , .
- migrationToken, .
- LocalStorage migrationLocalstorage. , JS-, iFrame relatimeboard.com/localstorage/ postmessage , .
Se o usuário foi diretamente para o novo domínio miro.com, foi realizada uma verificação para garantir que o usuário passasse na migração do token e LocalStorage. Se o usuário já concluiu a migração, ele permaneceu no domínio miro.com. Se você não o concluiu, ocorreu um redirecionamento no realtimeboard.com para receber um token (para isso, armazenamos dois sinalizadores nos cookies: migrationToken e migrationLocalstorage).
Esse esquema também funcionou bem para usuários de SSO que efetuaram login no domínio antigo realtimeboard.com. Foi adicionada uma lista de rotas que funcionavam sem migrar o token para o novo domínio. Eles incluíram uma rota para o SSO, que foi executada normalmente e redirecionada para / app / ou / login / dependendo do estado de seu trabalho, após o qual o mecanismo de migração de token foi conectado novamente.
Resultado
Passei um mês em pesquisa e preparação, outro mês em execução (em paralelo, participei de outros projetos). Com essa solução, conseguimos migrar usuários autorizados do domínio antigo para o novo e oferecer suporte a usuários que usavam o SSO para autenticação através do domínio antigo.