O Google encerrou sua plataforma de mídia social Google+ em 2 de abril de 2019. É difícil encontrar algum artigo técnico que não tenha mencionado o fim da era das redes sociais do Google. Porém, um alto nível de consistência na conectividade nos serviços da empresa havia recebido pouca atenção. Neste artigo, gostaria de compartilhar meus pensamentos sobre a maneira interna de consistência dos serviços do Google e o que isso significa para os usuários da API do Google quando se trata de um desligamento do Google+.
Do ponto de vista de um cliente, o uso das Fotos do Gmail e uma nova mudança para o Google Docs devem ser o mais claros possível - à primeira vista, esses serviços são independentes e unidos em uma plataforma que é um ponto de acesso chamado accounts.google.com . Porém, como desenvolvedores, sabemos que os termos "desligamento", "aquisição", "integração" envolvem grande significado (e também funcionam) para as pessoas que participam desse processo. Então, vamos analisar mais de perto o processo de uma das aquisições de serviços externos do Google e o que está acontecendo com a API de serviços assumidos e a API do Google.
Conta e ID do usuário
Além dos usuários que usam o Gmail e podem ouvir falar do Google Plus, também há um grande número de APIs para desenvolvedores que incluem identificadores de conta, o notório ID do usuário. O ID do usuário é o ID interno do Google, é isso que ajuda os serviços do Google a entender quem é quem. Ele apareceu em muitas APIs e vemos que não foi alterado de serviço para serviço.
Caos
Obviamente, para a implementação do SSO no serviço recém-absorvido, você não pode simplesmente pegar e transferir contas da base antiga para a nova "base de contas do Google". Acho que simplesmente não existe isso - existem muitos serviços entrelaçados, níveis de interação, cadeias de responsabilidade, serviços de gerenciamento de serviços. Sério, se você pensar bem, deve haver muitos, muitos, muitos níveis de conexões entre os serviços do Google para que tudo funcione. Mas então tudo não corre tão bem - em um esforço para popularizar o G +, ele usou o ID do usuário dos usuários que fazem parte do serviço SSO global.
Vamos voltar à tese. É necessário fazer alterações na API existente do lado absorvido da API e de outros serviços que agora podem começar a trabalhar com o novo serviço. Parece nada super complexo - adaptar a base de usuários existente do serviço aos serviços "comuns do google", criar pontos de interação com outros serviços para que eles possam usar o novo serviço para seus próprios fins. Mas não se trata de pequenos projetos - uma corporação do bem não perde tempo com insignificantes e absorve empresas multimilionárias, que, provavelmente, já estabeleceram infra-estrutura - caso contrário, não poderiam crescer em sua escala. Portanto, faz sentido deixar sua base de códigos, ou melhor, o núcleo do serviço e refazer os canais de entrada e saída dos links do serviço, para que se tornem compatíveis com o Google. Em seguida, o serviço se torna um serviço do Google. Suponhamos que, neste momento, ele já tenha sido testado e considerado bastante confiável pelas pessoas do Google responsáveis pela integração. Aqui está a parte mais interessante - o serviço pode ser integrado a outros serviços e / ou transferido de serviço para serviço. Em geral, não seria assustador se não fosse a tendência do Google de alterar o registro de serviços. Tome por exemplo fotos.
Aplicativo de desktop Picasa (2002) => Álbuns da web do Picasa - O Google adquire o Picasa (2004) => Picasa (2011) incorporado ao Google Plus => O Google Fotos é separado do Google+ (2015) => ...
Considerando a inércia do processo de integração, na maioria dos produtos, o Google ainda suporta APIs muito antigas. No momento da publicação do artigo, a API do Picasa ainda estava funcionando como antigamente quando o Picasa era um produto separado. Isso nos leva à conclusão de que, quando o Google integrou o Picasa como seu próximo serviço, eles criaram uma "ramificação" a partir do produto original e deixaram a antiga "ramificação" à mercê do destino, mas não desativaram sua API.
E então é hora de lembrar o motivo do fechamento do G +. Isso ocorreu devido a um problema de segurança relatado, mas, na realidade, pode haver ainda mais problemas de segurança devido à inconsistência em diferentes APIs.
Prova de conceito
Por exemplo, havia um serviço chamado PicasaWeb - o antecessor do Google Fotos . Está indisponível desde 2016, mas de acordo com a observação no final de uma postagem - sua API ainda funciona. A data de término desta API é 15 de março de 2019 . Este serviço foi digno de nota, pois permitiu obter correspondência de email e identificação interna do usuário. Como isso seria útil?
Caso desenvolvamos um validador de email . Nesse caso, essa API seria um maná do céu. Conhecendo um ID de conta do G +, podemos obter o nome de um usuário, uma foto e até informações adicionais. O truque é que você não pode obter o ID do usuário se esse usuário nunca fez login no nosso site. Mas, apesar disso, os usuários puderam postar fotos em álbuns da web vinculados a e-mail usando os antigos PicasaWebAlbums. Isso sugeriu que a API antiga permite acessar a conta do usuário usando o ID do usuário ou o email do usuário.
Vamos verificar: https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
https://picasaweb.google.com/data/feed/api/user/ - ponto final da API;
nosov@nodeart.io - e-mail do usuário para verificação (como podemos ver, não é necessário usar apenas e-mails do Gmail). Os usuários têm contas do Google Apps (esse fato ajuda a ser útil na verificação de geração de leads), os usuários com contas do Google+ também têm isso (vinculando um email de terceiros com antecedência), por exemplo, Yandex.ru
deprecation-extension = true - a indicação sobre um terminal eminente da API.
Se tentarmos passar um email inexistente , obteremos uma resposta clara e interpretada: “Não foi possível encontrar um usuário com o email noname@nodeart.io, o que leva à conclusão de que esse email não é válido. E ainda mais - se tentarmos enviar um endereço de grupo para a API, a resposta será "Usuário desconhecido". Seria possível distinguir a diferença entre emails pessoais do G-Suite e emails corporativos. É difícil dizer que podemos "capturar" dados pessoais dessa maneira se esses dados não foram compartilhados pelo usuário, mas isso foi bom para a validação global da lista de usuários via API.
Então, como essa imprecisão está vinculada ao desligamento do Google+?
Conclusões
O principal motivo para encerrar o Google+ foi o lapso de segurança, mais precisamente, a capacidade de obter dados do Google+ pelos serviços que não foram planejados e planejados anteriormente.
Além do Google+, o desligamento parcial de várias APIs é realizado. Por exemplo, você deve passar na auditoria paga para obter acesso ao gmail.api, o que torna essa API indisponível para a grande maioria dos desenvolvedores.
Citação
A taxa de avaliação é paga pelo desenvolvedor e pode variar de US $ 15.000 a US $ 75.000 (ou mais), dependendo do tamanho e da complexidade do aplicativo.
De fato, isso nos dá uma razão para pensar que o Google se enredou no sistema de interação entre serviços, pois as ações que anteriormente poderiam ser executadas simplesmente pela obtenção do escopo necessário, agora exigem validação manual por 15 a 75k USD e inclusão manual em a lista de permissões. Resta apenas adivinhar o que mais você pode fazer usando os recursos não documentados do rico ecossistema de serviços do Google e o serviço SSO em particular.
Para validar qualitativamente as listas de endereçamento , precisamos procurar novas formas não padronizadas de uso de APIs públicas, para que continuemos a explorar a Google \ Facebook API e outros serviços. (A propósito, o Facebook até recentemente tinha uma maneira semelhante de validação de email.)