我们使用 Windows Azure 云服务来托管我们的应用程序。Windows Azure 的一大特色是生产/登台模型。您可以将应用程序的客户端路由到生产服务器,同时可以测试在暂存服务器上运行的新代码。例如,您可以将 Azure 配置为将生产服务器指向http://www.coolapp.com,同时将同一应用程序的临时服务器指定为类似以下内容:http: //7f8e9d5ba73a4f7ea9ebd65a02ee195d.cloudapp.net。
从物理上讲,这两个服务器都是面向公众的。如果您知道暂存服务器的神秘 URL,您将能够像浏览 www.coolapp.com 一样轻松浏览应用程序。但是,URL 中 GUID 的存在使得人们几乎不可能猜到它,从而使登台服务器“私有”。这为应用程序的开发人员提供了一种很好的机制,可以在将新位发布到公众之前在登台服务器上部署和测试新位。一旦他们确保事情看起来不错,只需轻按一下开关,他们就会交换两台服务器,使登台服务器成为生产服务器,反之亦然。
这个模型给我们带来了一个与 Facebook 集成相关的小问题。为了能够集成 Facebook 插件,您必须向它们注册您的应用程序。然后 FB 将发出一个 AppId 和一个 AppSecret 密钥。这些键与您的应用程序的 URL 相关联。因此,为了让我的应用程序能够使用 FB 插件,我需要获得一组与 7f8e9d5ba73a4f7ea9ebd65a02ee195d.cloudapp.net 相关联的密钥,以及另一组与 www.coolapp.com 相关联的密钥。
当我阅读有关 Windows Azure 的信息时,他们确实敦促开发人员将登台服务器与生产服务器视为相同。它们之间的唯一区别应该是 URL。换句话说,Azure 不建议您的应用程序逻辑基于代码恰好在哪个服务器上运行,因为 Azure 对此没有固有的知识。如果您愿意,分期与生产只是一个方便的“抽象”。我想你在这里看到了问题。在上面的示例中,我必须使用 FB 发布的一组密钥,而不是另一组密钥,具体取决于我的应用程序在哪个 URL(生产与暂存)上运行。我想我不是第一个遇到这个问题的人。处理这个的正确方法是什么?一种明显的方法是嗅探 Request 对象的 URL 属性并以此方式分支我的逻辑。然而,直觉告诉我这是一个hack。还有其他想法吗?
问候,
阿基尔