User client on the server with a cookie

[diversario]

I need to connect from one server to another via sockets (target runs socket.io) and I need to be able to add session data to client socket connection, basically to make it look like it was coming from a browser with cookies. Is it possible at all?

[nponeccop]

+1. I need an ability to send cookies in handshake request when run from node.js. It seems a hook is needed to insert headers after XHR is open in https://github.com/LearnBoost/socket.io-client/blob/master/lib/socket.js

+1. We use Connect sessions for handshake authorization, which seems to be rather common, and we need to be able to test that in our integration tests.

[nponeccop]

@attentif How did you manage that? I had to patch socket.io so it passes Connect session object in handshake object.

Consider the following scenario: cookie and set-cookie headers are blocked by a reverse proxy for all HTTP requests but the socket.io handshake request. Can your implementation establish a session in this case?

@nponeccop The session must be established before opening the socket connection. We just check handshakeData.headers.cookie in the authorization function, which it seems is possible since v0.7 of Socket.IO. Our initial reference: http://www.danielbaulig.de/socket-ioexpress/

That means our implementation won't work in your scenario as we require a preliminary "login" request to establish the session.

[nponeccop]

See my approach here: socketstream/socketstream#219

It would be nice if we could join our efforts of pushing necessary patches to socket.io.

[missinglink]

What is the status of this?

I am trying to connect with a client written in node.js.
My server has an io.set('authorization',...) step defined

I keep getting the error handshake error No cookie transmitted when the client connects.
If the io.set('authorization',...) step is removed then the client connects without error.

Connecting from the browser works fine.

[rauchg]

Maybe a node-only option extraHeaders ?

[3rd-Eden]

Why would this be needed? We allow people to add querystrings to the connection call, which can be used on the server side again.

eg:

io.connect('/?foo=bar');

[rauchg]

@missinglink

Here:
https://github.com/LearnBoost/socket.io-client/blob/master/lib/socket.js#L149

We want to loop through handshakeHeaders option (which needs to be added and defaulted to {}) and call setRequestHeader on each.

[rauchg]

I agree, normally you should use query strings if possible.

[missinglink]

Thanks @3rd-Eden @guille. I'll modify my authentication to accept query string params

[3rd-Eden]

The main reason why we opted for using query strings is that it was the cross browser way of adding extra to a request.

[rauchg]

Yep, cross-browser cross-transport.

[sebpiq]

A case for custom headers ?

http://stackoverflow.com/questions/13381540/with-socket-io-how-to-handle-authentication-with-a-non-browser-client#comment18284570_13381540

Basically one big issue I think is that it is quite unsecure to put credentials or other sensitive information used for authentication in the url, as this might be logged.