Socket.io not sending cookies in the handshake causing the request to stall

Let me explain my setup. I have multiple domain names that are all CNAME records for a main domain name, such as example.com.

example.com -> serverIP

company1.example.com -> example.com

company2.example.com -> example.com

I’m basically developing white labeled versions of our software, where the software simply detects the referrer and knows which logos and stylesheet assets to load.

So that is all well and good, however when socket.io tries to handshake to it’s url that looks something like http://company1.example.com/socket.io/1/?key=123456, the request hangs in a pending state upon signing into the app. On the main domain, example.com, everything goes through just fine. The dfference is that the main domain sends in a cookie to the socket.io handshake URL whereas the company subdomains do not.

Does anyone have any ideas on how to fix this? It doesn’t appear to even be reaching the server and after a few minutes the pending request returns that it could not be completed.

Answer

You got two choices:

1. Don’t use cookies for authentication. Use a token a based method. As soon as the client gets connected to the app, just send the authentication token. You can save the token with localstorage, and for the first time, the token can be embedded in javascript or html by your server.

   If you wonder why you shouldn’t use tokens, read this from sockjs-node documentation, which implements something similar to socket.io

   Cookies are a contract between a browser and an http server, and are identified by a domain name. If a browser has a cookie set for particular domain, it will pass it as a part of all http requests to the host. But to get various transports working, SockJS uses a middleman

   an iframe hosted from target SockJS domain. That means the server will receive requests from the iframe, and not from the real domain. The domain of an iframe is the same as the SockJS domain. The problem is that any website can embed the iframe and communicate with it – and request establishing SockJS connection. Using cookies for authorisation in this scenario will result in granting full access to SockJS communication with your website from any website. This is a classic CSRF attack. Basically – cookies are not suited for SockJS model. If you want to authorise a session – provide a unique token on a page, send it as a first thing over SockJS connection and validate it on the server side. In essence, this is how cookies work.

   Also check this article as an example implementation.

   If you are still not convinced, then check choice number 2:

2. Keep using cookies. This might not work though. Upgrade to the latest socket.io(either 0.9.x or 1.x). Using 0.9.x set the origin config property. Or on 1.x set origins server option. You can set them to *:* or *example.com:*.

   Also check this question: CORS with socket.io