Description

mcclure

opened on Oct 5, 2020

Issue body actions

If I run the following test program with msgpack-javascript 2.1.0:

import { encode, decode } from "@msgpack/msgpack"
const map = new Map()
map.set("a", 1)
map.set("b", 2)
map.set("c", 3)
const encoded = encode(map,{initialBufferSize:128})
const decoded = decode(encoded)
console.log({map, encoded, decoded})

The output is:

Conclusion: Asking msgpack-javascript to encode a Map causes it to encode it as if it were an empty object.

Supporting Maps in some capacity would be good because if anything it is better to store Maps in msgpack than to store objects. Sometimes deserializing in JavaScript can cause problems or even security flaws if keys overwrite "special" javascript objects like hasOwnProperty or __proto__. Here is an example of such a problem. I suspect msgpack-javascript itself will not have any such security flaws, but it is easy for client code to have such security flaws and the security issues can be sidestepped by using Maps instead of objects.

Activity

1. gfx commented on Oct 5, 2020

   

   gfx

   on Oct 5, 2020

   Member

   More actions

   Thank you for your report.

   This is the specification and won't be fixed because MessagePack is designed to communicate in multi-languages. I won't add any flavors by default.

   However, any JavaScript programs use lots of non-primitive objects, so the MessagePack spec has extensions.
   See extension types for details.

   Also, I'd like to add extensions to handle non-primitive objects like ES2015's Map, just like as browsers do.
2. joshyrobot commented on Jun 11, 2021

   

   joshyrobot

   on Jun 11, 2021

   More actions

   Sorry, where in the spec does it say something incompatible with Maps? As far as I can tell, the spec actually places no restriction on map keys, so the current implementation seems to be non-compliant, and the only way to make it compliant is to decode into Maps instead of plain objects.

   Reacted by Gavin Wong and aetherus
3. mcclure commented on Jun 12, 2021

   

   mcclure

   on Jun 12, 2021

   Author

   More actions

   To concur with what @joshyrobot is saying, what we're looking for is not so much a way to encode maps in addition to objects, we're looking for a way to encode maps instead of objects— something like an alternate mode in which maps are always created and consumed and vanilla javascript objects are never created or consumed.

   Reacted by aetherus
4. jcc10

   added a commit that references this issue on Apr 1, 2023

   Update README.md

   07900e5

Issue actions