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.
You got two choices:
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
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:
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
originsserver option. You can set them to
Also check this question: CORS with socket.io