socket.request.connection.remoteAddress is undefined for AJAX node.js clients

Issues such as #1483 and #1387 illustrate that socket.request.connection.remoteAddress is not always defined.

In #1387, someone pointed out that a websocket client’s IP address is present, but that a client using a polling transport (like socket.io-client does by default when running in node.js) does not have remoteAddress present.

Test case:

server.js

var io = require('socket.io')(5555);

io.on('connection', function (socket) {
    console.log(socket.request.connection.remoteAddress);
});

client1.js (running this should produce undefined on the server console output)

var io = require('socket.io-client')('http://localhost:5555');

client2.js (running this should produce the client’s IP address on the server console output)

var io = require('socket.io-client')('http://localhost:5555', { transports: ['websocket'] });

Is there any particular reason that there is not a way to retrieve a client’s IP address if they are using a node.js client with the AJAX transport? I would prefer not to require all of my clients to manually override the transport.

[calzoneman]

Ok so the cached engine.io address can actually be accessed without any patching to socket.io via socket.client.conn.remoteAddress, but this depends on this commit, which seems not to have affected the version being pulled from npm. I suspect that either the change wasn’t published, or because the patch version didn’t change, npm is caching the wrong version.

[polkovnikov-ph]

@darrachequesne I ended up forking and patching source code anyway. Figuring out, which of the requests counts as handshake, whether it will be really stored at any moment of operation, what it will be named in the next version of the library, how to put requests through an Agent, how to use socket.io-client with a cookie and other headers (for either part of handshake, websockets included) and how to get around other bugs that are not closed for 4 years is just way too time consuming.