Open hilkeheremans opened 6 years ago
This issue can also affect hexadecimal Mongo ObjectIds. Usually, an ObjectId will contain a mix of alpha and numeric characters, but it can happen that your timestamp, random, and increment each happen to encode to all numeric characters, in which case it mongo-querystring will convert it to a number.
There's not really a safe way for the library to detect what the user's intent is, as they may happen to be passing a 24-digit number in the URL, but the custom
option to bypass parsing should cover the ObjectId case as well as the general hexadecimal case.
However, this approach would opt out of the parsing logic for arrays. If you definitely know your hexadecimal values will start with '0x', it seems you could subclass MongoQS and override parseStringVal to return an unmodified string, or strip the '0x', etc.
Hi there,
First off: great work.
We've bumped into a bit of an issue when trying to pass long hexadecimal strings. When passing these,
mongo-querystring
will coerce this into a number. Example:0xfbede9b15fbeec9e1579653ac3af52b0a54ec2a3725150c64e681264cb18cbf6
gets converted to0
, which is clearly not the intention of the caller.Ideally (but this is debatable), I believe values in hexadecimal notation should/could be passed on as strings instead of numbers. Most of the time in Mongoland, this kind of value is stored as a string (eg a hash of some sorts).
Questions that remain could be:
0x
enough or do we want to go more in-depth?)0x
or not? (guess this could be a user option)Perhaps start a brief debate on this, and I'd be happy to provide a PR once you settle on a potential approach [if any, of course]? I'm also aware number parsing can be disabled altogether, but we have a need for parsing to numbers in other cases.
PS: for now, although horribly inefficient and not robust since it can result in false positives, this can be worked around by using the
~
operator.