长轮询服务器原则（客户端身份验证） [英] Long polling server principle (client authentication)
问题描述
让我们说，我有工作的长轮询服务器，因为它应该 - 当新的客户端连接到网站（他刚接匿名无需验证），新的GUID发出并存储在一个签名的cookie识别此连接在客户端和服务器之间投票。
Let's say that I have a long poll server which works as it should - when new client is connected to the website (he just connects as anonymous without authentication), new GUID is issued and stored in a signed cookie which identifies this connection during polls between client and server.
现在客户想登录并继续作为身份验证的用户。问题是，长轮询服务器（node.js中）和Web框架（ASP.NET）正在为独立系统。我可以使用ASP.NET（MVC）特定的身份验证机制，但从web框架点登录，但是这并不影响长轮询服务器（我仍然被称为一些GUID的家伙）。我应该如何安全但从长轮询服务器点验证用户？是否有任何最佳实践为这种情况？认证的客户应认证过程后，进一步通过他独特的键（比方说，一个邮件地址，而不是GUID）标识。
Now the client wants to log in and continue as authenticated user. The problem is that long poll server (node.js) and web framework (ASP.NET) are working as standalone systems. I can use ASP.NET (MVC) specific authentication mechanism to log in from web framework point of view, but this doesn't affect long poll server (where I'm still known as some GUID guy). How should I securely authenticate user from long poll server point of view? Are there any "best practices" for this scenario? Authenticated client should, after authentication procedure, be identified further by his unique key (let's say a mail address instead of GUID).
推荐答案
一瘦我能想象：
- 问题会话ID，要么使用ASP.net东西，或者发出一个额外的，你可以在需要的时候必须挂接到ASP.net AUTH以使它无效 -
- 当执行长轮询确保它发送Cookie，从而使Node.js的服务器接收它。
- 保存GUID来，你可以从ASP和Node.js的访问DB。
剩下的应该清楚，对于其数据块可以使用，我没有任何经验，但有一个DB相当的很多包装的Node.js的，虽然其中不少是没有维护或功能不完整
The rest should be clear, as for which DBs you could use, I don't have any experience, but there a quite of DB a lot of wrappers for Node.js, although many of them are unmaintained or not feature complete.
您应该Node.js的维基查看数据库列出并看看每一个，别忘了要搜索的谷歌有关，并检查这些问题，看看是否有什么大的想你用它去了。
You should check out the database listing in the Node.js wiki and take a look at each one, don't forget to search on Google about it and check the issues to see if there's anything big missing before you go with it.
哦，另一个（DBless）解决方案，如雨后春笋般在我的脑海：
Oh and another (DBless) solution springing to my mind:
- 通过ASP.net执行AUTH
- 在当前的Node.js收到AUTH饼干，将它们转发到一个特殊的ASP.net页面（你可以只从本地主机访问），只是告诉Node.js的这一请求是否有效（这也可以给Node.js的一些用户数据）
- 只有当请求有效，启动长轮询
这应该几乎没有引入任何延迟在同一台服务器上正在做的时候。
This should hardly introduce any lag when being done on the same server.
这篇关于长轮询服务器原则（客户端身份验证）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
