socket.io handshake auth is undefined and not showing auth in handshake

[raghu-gade]

I’m using a Socket.IO server and client application. Below is my client-side code:

this.socket = io("https://my-server-app.cloudapp.azure.com", {
  transports: ["websocket"],
  path: "/nodeserver/socket.io/",
  auth: {
    userId: userId,
    token: token,
  },
});

The Socket.IO server is deployed in an AKS cluster. Here’s the server-side code:

var io = require('socket.io')(app.listen(port), { path: "/nodeserver/socket.io/" });
io.sockets.on('connection', function (socket) {
  console.log("Handshake data:", socket.handshake);
  console.log(JSON.stringify(socket.handshake.auth));
});

Issue
When running the application locally (localhost:8083), the auth variable in the handshake data is populated correctly, as shown in the logs:

Handshake data: {
  headers: {
    host: 'localhost:8083',
    connection: 'Upgrade',
    pragma: 'no-cache',
    'cache-control': 'no-cache',
    'user-agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36',
    upgrade: 'websocket',
    origin: 'http://localhost:4200',
    'sec-websocket-version': '13',
    'accept-encoding': 'gzip, deflate, br, zstd',
    'accept-language': 'en-US,en;q=0.9',
    'sec-websocket-key': 'ATD5Ct1HLN3FDAajDfRfIQ==',
    'sec-websocket-extensions': 'permessage-deflate; client_max_window_bits'
  },
  time: 'Thu Dec 19 2024 11:36:44 GMT+0530 (India Standard Time)',
  address: '::1',
  xdomain: true,
  secure: false,
  issued: 1734588404811,
  url: '/nodeserver/socket.io/?EIO=4&transport=websocket',
  query: [Object: null prototype] { EIO: '4', transport: 'websocket' },
  auth: {
    userId: '[email protected]',
    token: 'mytoken'
  }
}

However, when accessing the server through the AKS-deployed URL (https://my-server-app.cloudapp.azure.com), the auth field in the handshake data is missing:

Handshake data: {
  headers: {
    host: 'https://my-server-app.cloudapp.azure.com',
    connection: 'Upgrade',
    pragma: 'no-cache',
    'cache-control': 'no-cache',
    'user-agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36',
    upgrade: 'websocket',
    origin: 'http://localhost:4200',
    'sec-websocket-version': '13',
    'accept-encoding': 'gzip, deflate, br, zstd',
    'accept-language': 'en-US,en;q=0.9',
    'sec-websocket-key': 'ATD5Ct1HLN3FDAajDfRfIQ==',
    'sec-websocket-extensions': 'permessage-deflate; client_max_window_bits'
  },
  time: 'Thu Dec 19 2024 12:20:20 GMT+0530 (India Standard Time)',
  address: '::1',
  xdomain: true,
  secure: false,
  issued: 1734588404811,
  url: '/nodeserver/socket.io/?EIO=4&transport=websocket',
  query: [Object: null prototype] { EIO: '4', transport: 'websocket' }
}

Socket.IO Server: "socket.io": "^4.7.5" and
Socket.IO Client: "socket.io-client": "^4.7.5".
The auth object is passed correctly when testing locally.
It’s not appearing when accessed through the AKS-deployed URL.

Expected Outcome
The auth object should be included in the handshake data for both local and deployed environments.

How can I ensure the auth data is transmitted and logged correctly in the AKS environment?

[darrachequesne]

Hi! That's weird indeed. Does it happen on all browsers? Could you please check the packets in your network console? You should see something like:

Here, the 40{"hello":"world"} message comes from:

const socket = io({
  transports: ["websocket"],
  auth: {
    hello: "world"
  }
});

In your case, is it simply 40 (without the auth part)?

[raghu-gade]

Socket connection successful initially then after disconnected and the response in network console like this

and in console like this

[darrachequesne]

The auth part is indeed present in your screenshot (40{"userId":...}) so it should work properly, on initial connection and also upon reconnection.

You can print debug logs with the DEBUG environment variable on the server, for example with DEBUG=engine*. This should print the raw WebSocket packets received by the server.

[parv8055]

I think it is cors error try adding cors in the server side