共 5 篇相关文章
2007年，雅虎中国高调推出“终身免费邮箱”，并扬言要与网易打持久战。然而仅六年后，这项“终身”服务便宣告关闭。 这篇文章复盘了这起商业承诺的演变。作者指出，邮箱本身很难直接盈利，其对互联网巨头的真正价值在于构建一个核心“用户体系”，并以此推行“通行证策略”——用一个账号打通所有服务，从而深度了解用户行为，为商业决策提供支撑，例如谷歌的Gmail与微软的Hotmail。 对于运营雅虎中国的阿里而言，这套逻辑并不适用。阿里自身拥有庞大的电商用户体系和独立的IM工具（阿里旺旺），并不依赖雅虎邮箱来建立通行证。从独立业务看，雅虎中国邮箱也并非市场领导者。因此，在阿里逐步摆脱对雅虎总部的依赖后，关闭这个既不赚钱又缺乏战略意义的业务，便成了顺理成章的选择。文章揭示了一个朴素的商业逻辑：巨头的承诺往往服务于特定阶段的战略，当战略本身发生变化时，“大话”也就有了合理的注脚。
这篇讲的是，很多Drupal站点都在用第三方模块实现单点登录，但作者指出，其实Drupal本身内建了这个能力，完全不需要额外的模块和配置。 要应用这个方法，你的站点需要满足几个硬条件：它们必须在同一主域名下（如 `www`、`forums`、`subsite` 这种子域名形式），全部使用MySQL，并且这些站点的服务器在物理上能够互相访问数据库。如果符合要求，核心方案其实非常精简，只需要在两个站点的 `settings.php` 文件里添加约20行代码。 其原理在于巧妙地结合了两个特性：一是Drupal原生支持通过“表前缀”让多个站点共享一个数据库；二是MySQL支持跨数据库查询。通过配置，可以让不同站点的用户会话表实现数据共享。最后，只需正确设置 `cookie domain`，确保浏览器在主域名及其子域名下共享会话cookie，单点登录就宣告完成。对于符合架构要求的站点，这是一个既轻量又高效的原生解决方案。
这篇讲的是互联网上一个经典又实用的问题——如何让用户登录一次就能畅游多个网站？作者从单点登录技术的一般模型讲起，清晰地拆解了用户、身份提供者和服务提供者这三角关系。文章的核心篇幅，则聚焦在两种主流方案的对比与剖析上。 一方面，详细拆解了当时微软主导的Passport协议。它基于Kerberos机制，通过中央服务器统一管理认证，流程清晰但“中心化”色彩浓厚，安全与隐私曾引发广泛质疑。另一方面，深入剖析了自由联盟（Liberty Alliance）提出的开放规范。它采用SAML标准，构建的是一个“联邦式”的身份网络，允许多个独立的身份提供者共存，更注重分布式的信任与用户对个人信息的掌控权。 文章不止于介绍原理，更难得的是结合了“个人域名作为身份标识”的实现案例，并最终回归现实，冷静分析了这些协议在可行性上的差异与各自存在的不足。对于想理解SSO技术演进脉络、对比“中心化”与“联邦式”身份架构优劣的读者来说，这篇文章提供了非常扎实的技术底本和清晰的视角。
这篇讲的是第三方登录如何从理想化构想，逐步演变为成熟实践的历程。 文章从OpenID的初衷切入——它试图解决用户需要在每个网站重复注册的烦恼，但很长一段时间进展缓慢。作者结合自身经历指出问题关键：用户记不住专属的OpenID地址和密码，而网站则不愿将登录入口的控制权与稳定性完全托付给不可控的第三方提供商。 真正的转折点在于，当Google、Yahoo!这类巨头成为OpenID提供商时，问题迎刃而解。一方面，它们的技术与商业实力保证了服务的稳定可靠；另一方面，它们本身就是众多常用服务的提供方，用户天然对其抱有信任。文章由此得出了一个颇具启发性的结论：到了这个阶段，协议本身（是否OpenID）已不重要，重要的是由谁来提供这项服务。第三方登录的成功，实质上是平台级公司成功建立数字信任的副产品。
这篇文章讨论的是中小型Web服务在用户注册环节上的一个务实思路：是否真的需要从零搭建一套独立的账户系统？ 作者从Robert提出的一个有趣问题出发——未来，我们是否可以完全依赖Google、Facebook这类已有的第三方账户服务来作为自己应用的“通行证”？这并非一个全新的设想，作者回忆起自己早前也曾探讨过“Facebook能否成为网络身份证”的话题，并提及了当年对类似微软Passport这种第三方认证模式的思考。 文章的核心价值在于，它没有停留在理论层面，而是将这个方案置于具体的中小型服务场景中去权衡。它引导读者思考：借助成熟的第三方认证，开发者或许能大幅简化开发、降低维护成本，并提升用户的初始体验。但同时，这也涉及对用户数据自主性、平台依赖风险以及服务长期演进可能性的考量。作者的回忆与思考，为这个略显老生常谈却又常新的话题，增添了一份实践者的视角。
