Long polling server principle (client authentication)

Question

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.

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).

Crissman

Answer 1

One thin I could imagine:

1. Issue a session ID, either use the ASP.net stuff, or issue a extra one, you may have to hook into the ASP.net auth to invalidate it when needed-
2. When doing the long polling make sure to send the cookie with it, so that the Node.js server receives it.
3. Save the GUID to a DB that you can access from both ASP and 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.

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.

Oh and another (DBless) solution springing to my mind:

1. Do the auth via ASP.net
2. When Node.js receives the auth cookies, forward them to a special ASP.net page (you can make that only accessible from localhost) that just tells Node.js whether this request is valid (it could also give Node.js some user data)
3. Only if the request is valid, start the long polling

This should hardly introduce any lag when being done on the same server.

Lucielucien

Thanks for ideas. I was also thinking about shared DB solution first. Second solution sounds interesting, especially the localhost page which can return currently authenticated user identifier (ASP.NET User.Identity.Name property). – Crissman

Answer 2

I am currently facing the same problem and here is what I am going to do:

I have a REST server in Java which serves the API to my web client. For the long polling I have written a small node.js server.

1. The client connects to node.js sending username/password (via HTTPS). You can also pass a Session token.
2. node.js calls into the REST server to auth the user with the given credentials
3. If the user is authenticated node.js waits or sends 401 otherwise

The benefit is that the node.js server does not need to know anything about the DB structure, doesn't need to include sql calls. This also allows to rewrite the server with Python twisted if you want to.

Winsome