谷歌于2019年4月2日关闭了其社交媒体平台Google+。很难找到一些尚未提及Google社交网络时代结束的技术文章。 但是，公司服务内部连接的高度一致性受到关注。 在本文中，我想分享一下我对Google服务一致性的内部方式以及Google+关闭时对Google API用户的意义。
从客户的角度来看，应该尽可能清楚地使用Gmail照片以及进一步转移到Google文档-乍一看，这些服务是独立的，并且在一个称为accounts.google.com的访问点的平台内统一在一起。 。 但是，作为开发人员，我们知道，“停工”，“接管”，“整合”这些术语对于参与此过程的人们而言具有巨大的意义（并且也可以工作）。 因此，让我们仔细看一下Google进行的一项外部服务收购的流程，以及接管服务API和Google API的情况。
帐号和用户ID
除了使用Gmail并可能听说过Google Plus的用户外，还为开发人员提供了大量的API，其中包括诸如帐户标识符，臭名昭著的userID之类的东西。 userID是Google的内部ID，可以帮助Google服务了解谁是谁。 它出现在许多API中，并且我们发现它在服务之间并没有改变。
混乱
显然，为了在新吸收的服务中实施SSO，您不能简单地将帐户从旧基础帐户转移到新的“ Google帐户基础”。 我认为根本没有这样的东西-有许多相互关联的服务，交互级别，责任链，服务管理服务。 认真地说，如果您考虑一下，那么Google服务之间必须有很多很多层次的连接，一切才能正常工作。 但是随后一切都变得不顺利-为了推广G +，它使用了属于全球SSO服务的用户的userID。
让我们回到本文。 有必要从API的吸收方面和现在可以开始使用新服务的其他服务进行更改。 看起来没有什么超级复杂的-使服务的现有用户群适应“通用google”服务，创建与其他服务的交互点，以便他们可以将新服务用于自己的目的。 但这不是关于小项目的事情-一家好公司不会浪费时间在琐事上，而是吸收数百万美元的公司，而这些公司很可能已经建立了基础设施-否则，它们就无法发展到规模。 因此，保留其代码库（或更确切地说，服务的核心）并重做服务链接的输入输出通道以使其与Google兼容是有意义的。 然后该服务成为Google服务。 假设目前，它已经过测试，并且由负责集成的Google员工认为非常值得信赖。 这是最有趣的部分-服务可以集成到其他服务中和/或在服务之间进行转移。 通常，如果不是因为Google倾向于更改服务注册，就不会感到恐惧。 以照片为例。
Picasa桌面应用程序（2002）=> Picasa网络相册-Google收购了Picasa（2004）=>合并了Google Plus的Picasa（2011）=> Google相册与Google+分开（2015）=> ...
考虑到集成过程的惯性，在大多数产品中，Google仍然支持非常古老的API。 在本文发表时，Picasa API仍可以像回到Picasa单独产品时那样工作。 这使我们得出以下结论：当Google将Picasa集成为他们的下一项服务时，他们从原始产品创建了一个“分支”，而将旧的“分支”交给了命运，但没有关闭其API。
然后是时候回顾关闭G +的原因了。 发生这种情况的原因是报告了一个安全性问题，但实际上，由于不同的API不一致，可能还会出现更多的安全性问题。
概念证明
例如，有一项名为PicasaWeb的服务-Google Photos的前身。 自2016年以来不可用，但根据帖子结尾的注释-其API仍在运行。 该API的结束日期为2019年3月15日 。 该服务值得注意，因为它允许电子邮件和内部用户ID匹配。 有什么用？
如果我们开发了一个电子邮件验证器 。 在这种情况下，该API可能是天上掉落的甘露。 通过G +了解帐户ID，我们可以获得用户名，照片甚至其他信息。 诀窍是，如果该用户从未登录过我们的网站，则无法获得userID。 但是尽管如此，用户仍可以使用旧的PicasaWebAlbums在与电子邮件链接的网络相册中发布图片。 这表明旧的API允许使用userID或用户的电子邮件访问用户的帐户。
让我们检查一下： https : //picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
https://picasaweb.google.com/data/feed/api/user/-API的端点；
nosov@nodeart.io-用于验证的用户电子邮件（如我们所见，不需要仅使用Gmail电子邮件）。 用户拥有Google Apps帐户（这一事实有助于进行有关线索生成的验证），拥有Google+帐户的用户也拥有此帐户（通过预先链接第三方电子邮件），例如Yandex.ru
deprecation-extension = true-有关即将到来的API端点的指示。
如果我们尝试传递不存在的电子邮件 ，则会得到清晰的解释响应：“无法找到电子邮件地址为noname@nodeart.io的用户，这导致该电子邮件地址无效的结论。 甚至更多-如果我们尝试将群组邮寄地址发送到API ，答案将是“未知用户”。 这样就可以区分个人G-Suite电子邮件和公司电子邮件。 很难说，如果用户不共享这些数据，我们可以通过这种方式“捕获”个人数据，但这对于通过API对用户列表进行全局验证很有用。
那么，这种不精确性如何与Google+关闭相关联？
结论
关闭Google+的主要原因是安全漏洞，更确切地说，是通过事先未计划和计划的服务从Google+获取数据的能力。
除了Google+，还会执行各种API的部分关闭操作。 例如， 您应该通过付费审核才能访问gmail.api ，这使绝大多数开发人员都无法使用此API。
引文
评估费由开发人员支付，视应用程序的大小和复杂性而定，可能在15,000美元至75,000美元（或更多）之间。
实际上，这使我们有理由认为Google已经纠缠于服务之间的交互系统，因为以前只需通过获取所需范围即可执行的操作，现在需要人工验证（需支付17.5万美元至7.5万美元）并手动包含在其中白名单。 只是猜测您可以使用Google丰富的服务生态系统（特别是SSO服务）的未记录功能还能做什么。
为了定性验证邮件列表 ，我们将需要寻找使用公共API的新的非标准方式，因此我们将继续探索Google \ Facebook API和其他服务。 （顺便说一下，直到最近，Facebook都采用了类似的电子邮件验证方式。）