我们有2个应用程序，一个在Nodejs中，另一个在aspx中。
登录页面位于Nodejs中。我需要的是从登录页面创建一个会话并在aspx应用程序中验证我的用户，以便以后在aspx应用程序中导航。
作为网络开发的菜鸟，我不知道从哪里开始或搜索什么。
提前致谢
答案 0 :(得分：3)
因此，我可以通过以下几种方式来实现这一目标，具体取决于您当前对这两种应用程序的意图以及执行您所做的事情的原因。我会尝试在这里列出一些专业人士和缺点。我再说一遍，对于新的网络开发者来说，没有什么是我认为容易的;您的团队中是否有其他人拥有一种或两种技术的经验？
1）可能最简单的选择，如果你能做到这一点就是让Node.js进程成为网关。 ASP.NET应用程序根本不需要对用户进行身份验证，Node.js应用程序充当ASP.NET应用程序的完全反向代理。如果你可以支持它，这很有效，你可以通过让Node.js应用程序登录到ASP.Net应用程序（通过你想要的任何方法;基本身份验证，表单登录，等等）来保护它。如果您需要ASP.Net应用程序了解当前上下文中的用户，那么您可以将所需的任何信息推送到请求标头中（例如，如果它们共享同一个数据库，则您可以输入标识符节点应用程序已经过身份验证的用户）如果您希望ASP.NET应用程序可以单独访问以及通过节点应用程序访问，那么节点应用程序将成为众多用户之一，并且asp.net应用程序需要HTTP模块来规范用户信息是否来自会话或来自Http标头。最简单的方法是让Http模块检查当前用户是否具有给定角色（例如NodeApp）并登录，然后将用户信息从HttpContext复制到新的Session变量（即应用程序的其余部分使用），或者在数据库中查找代理用户并执行相同操作。基本上，应用程序的其余部分永远不会相信HttpContext的当前用户在此时做出决定。
Pro：相当简单的架构，不依赖于每个应用程序所在的域。这两个应用都需要访问用户数据库才能正常运行。
Con's：如果由于某种原因，应用无法访问同一个用户数据库，那就不行了。进行代理有一些开销（不多，但仍然存在）。无论你是否正在谈论“真实的”，还是有点大脑弯曲。用户或节点＆＃39;用户，你必须保持直线。
2）OAuth（或OpenID）是最符合标准的选项。在这种情况下，您将Node.js应用程序设置为OAuth提供程序，并将ASP.NET应用程序设置为OAuth使用者。然后，用户可以使用他们的节点用户名和密码登录，并让Node应用程序通过现有的身份验证模块将身份验证令牌传递给ASP.NET应用程序。
专业人员：在ASP.NET方面编写的代码少于上面的示例，符合标准。如果您以后想要，可以切换（或添加）OAuth提供程序
Con's：为用户提供更多间接（在应用之间重定向）。这可能会被最小化，但您需要非常熟悉OAuth协议。
3）会话共享（如果其他人正在对你进行会话劫持......）。如果你在同一个域上，那么Node.js应用程序可以简单地写出ASP.NET会话和autah cookie，就像ASP.NET一样。我只是简单地说，但是有很多关于ASP.NET机制的细节，你需要了解它才能做到正确。 http://support.microsoft.com/kb/910443。主要的一点是，您需要将ASP.NET会话存储放在数据库中，然后让Node.js管理从那里添加和删除元素，以便在ASP.NET查看会话和放大器时;在给定请求上使用auth cookie，它可以在它希望找到它们的位置找到它们，然后ASP.NET进程会在那里找到它们并采取相应的行动。
专业人士：使用已经到位的ASP.NEt机器到某种程度 康纳斯：考虑到所有事情，可能非常脆弱。您的node.js应用程序需要访问ASP.NEt应用程序将用于解密会话内容的machineKey。您需要确保使用相同的加密算法，并且这两个应用都将耦合到同一会话存储。
4）在ASP.NET中滚动您自己的成员资格提供程序，以向Node应用程序发出Forms Auth票证。这有点类似于1和3的混合。在此选项中，Node应用程序在对用户进行身份验证后，会向ASP.Net服务器上的Login端点发送另一个请求，为其提供根据需要识别自身的凭据（例如，已经以某种方式加密的共享密钥）。它还可以提供您想要的任何用户详细信息。然后，您可以在ASP.NET代码中手动调用Forms Authentication api，为最终用户创建一个票证（http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket.aspx），即不自行计算;会话商店可以在任何地方。对Node.js应用程序的响应将包括auth cookie中的故障单数据，因此您的Node.js应用程序可以将该数据传输回您的用户，以便下次他们向ASP.nEt应用程序发出请求时，他们和＃39;将拥有由asp.net生成的有效身份验证cookie。
专业人士：从ASP.NET的角度来看，比＃3更灵活，比＃1更少的用户捣乱。 Con's：仍需要同一域上的两个应用程序，仍然需要两者之间的大量集成。如果您搞砸了您的会员资格提供者，您可能会意外地在您的安全保护中创建漏洞。
总的来说，我认为OAuth解决方案是最好的解决方案，但这些都是我能想到的方法。