You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 to 0, 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:
How do we detect hexadecimal notation? (is 0x enough or do we want to go more in-depth?)
What if we want this to convert to binary instead (some store this kind of value as binary instead, but I'd like to think this is a rare case)
Should we strip the 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.
The text was updated successfully, but these errors were encountered:
hilkeheremans
changed the title
Hexadecimal numbers are coerced into numbers
Hexadecimal strings are coerced into (incorrect) numbers
Nov 20, 2017
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.The text was updated successfully, but these errors were encountered: