【发布时间】：2012-03-05 20:12:27
【问题描述】：
我开始在 Azure 上使用 node.js 开发应用程序。我使用everyauth 来提供身份验证，因为我想支持许多不同的身份验证方法。我计划部署到 Azure。我遇到的潜在问题是everyauth 需要connect.session 助手。运行多个实例时，这是否适用于 azure？还是我需要一个替代的会话提供者？
【问题讨论】：
标签： node.js azure connect everyauth
【发布时间】：2012-03-05 20:12:27
【问题描述】：
我从未在 Azure 上使用过 Node.js，但是：
每个人
查看everyauth 的文档，有一种针对Windows Azure ACS 进行身份验证的方法。请参阅readme for more information 中标题为Setting up Windows Azure Access Control Service (ACS) Auth 的部分。那里没有关于它不能在 Azure 本身上运行的说明，所以我会推断你可以在 Azure 上使用它。
连接天蓝色
还有一个名为 connect-azure 的项目，它似乎正在使用 connect.session，所以我再次推断它可以在 Azure 上运行。
联系 Azure 支持
如果您已经是客户，您可以contact support for help。
试试看
因此，如果您有 Azure 环境设置，我肯定会说值得一试。
【讨论】：
-
感谢您查看此内容。设置测试环境的问题在于，如果它是一个问题，它只会非常偶尔地表现出来。如果 Azure 在本地存储会话并且您并不总是访问同一台机器（没有粘性会话），这只会是一个问题。另外，我目前正在测试环境中工作，并且不想设置实时服务器，直到我不得不这样做。 connect-azure 可能很有用，它用 table-storage 替换了默认会话提供程序，所以如果默认提供程序不起作用，我可能会使用它。
这是不久前被问到的，但我想我还是会尝试回答。似乎连接会话依赖 cookie 来维护会话。 Azure 有不同的负载平衡策略，具体取决于您使用的内容：
WebRole/WorkerRole - LB 没有任何关联性，因此来自您的客户端的请求可能最终会出现在不同的后端实例中。这将抛弃任何会话管理连接正在做的事情。这是分布式云架构的副作用：您不希望任何后端节点成为事实来源，因为它可能会宕机。因此，您需要做的是弄清楚如何将 connect 的 cookie 存储外部化并让所有后端共享它。这样无论哪个后端收到请求，它都会知道会话。
网站 - 在这种情况下，LB 将实际上尝试将客户端连接固定到给定的后端实例，因此基于 cookie 的会话可以在没有任何更改的情况下工作。如上所述，您正在牺牲故障转移。
【讨论】：