I am trying to make an RESTful request to an api. The endpoint needs a number (actually money value), which cannot exceed the normal fractional digits for that currency.
I cannot use a String -> 500 - Bad request
If I use a double I get an error for doubles that have rounding errors (and thus to many digits).
So in the end if I have a value like "23.42", I need to pass this to my json as 23.42 without quaotation marks.
I am using java and the original value is stored as a BigDecimal.
I am using GSON if this is important
Related
I am generating random OTP-style strings that serve as a short-term identifier to link two otherwise unrelated systems (which have authentication at each end). These need to be read and re-entered by users, so in order to reduce the error rate and reduce the opportunities for forgery, I'd like to make one of the digits a check digit. At present my random string conforms to the pattern (removing I and O to avoid confusion):
^[ABCDEFGHJKLMNPQRSTUVWXYZ][0-9]{4}$
I want to append one extra decimal digit for the check. So far I've implemented this as a BLAKE2 hash (from libsodium) that's converted to decimal and truncated to 1 char. This gives only 10 possibilities for the check digit, which isn't much. My primary objective is to detect single character errors in the input.
This approach kind of works, but it seems that one digit is not enough to detect single char errors, and undetected errors are quite easy to find, for example K37705 and K36705 are both considered valid.
I do not have a time value baked into this OTP; instead it's purely random and I'm relying on keeping a record of the OTPs that have been generated recently for each user, which are deleted periodically, and I'm reducing opportunities for brute-forcing by rate and attempt-count limiting.
I'm guessing that BLAKE2 isn't a good choice here, but given there are only 10 possibilities for the result, I don't know that others will be better. What would be a better algorithm/approach to use?
Frame challenge
Why do you need a check digit?
It doesn't improve security, and a five digits is trivial for most humans to get correct. Check if server side and return an error message if it's wrong.
Normal TOTP tokens are commonly 6 digits, and actors such as google has determined that people in general manage to get them orrect.
I'm looking for an overview of the internal data representation and earliest/latest dates supported by typical time libraries in different programming languages.
I can remember reading a webpage about that a while back but can't find it any more after dozens of Google search term refinements.
I didn't see the code of all major libs to be sure about that, but I guess many of them store data as fields, with most of them being numbers, such as year, month, day, hour, minute, etc.
The limits are either the upper/lower bounds of the respective numerical types, or some artificial value (such as "year 1 million" to represent a "very far future").
I think it also depends on the types being represented:
If the type represents only a local date (day/month/year, without hours and no timezone/offset), then the limits should be the upper/lower bounds of the type used to store the year value, or some artificial value.
If the type represents a timestamp (number of seconds/milliseconds/whatever-precision-of-seconds-the-API-supports since unix epoch), the limit can be the maximum value of the type used to store this value, or some artificial limit value.
And so on. But each of the cases above might give you a different limit, and the consistency between limits from different types will depend on the API.
Is that what you're asking?
Some API's, such as in Java, has documented limits for each type:
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#MIN
https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html#MIN
And note how the limit is different for each type.
I'm developing one system, where Badges will be created with a QRCode for each User, and I need to read that QRCode and show specific information to the user on the public screen.
QRCode reading is a little 'tricky'. When I did something like this, I was using MySQL with enumerated Ids (1, 100, 2304, 9990)... Witch is only about 5 characters.
However, MongoDB keys (DB that I'm using now) consists of a biggg key such as 52d35bf26bda8a5c8f8a22a8 witch has MANY characters.
What is the problem with that: QRCode becomes larger (more data, bigger the size), and becomes harder to read it fast on the WebCam (even in HD).
So, here is my idea: Use part of the Id, So that: 52d35bf26bda8a5c8f8a22a8 becomes perhaps 52d35bf26bd.
The question is really simple: Can I safely use the partial ID Key, without having re-occurrences? The maximum elements I will have, will be about 1000 order.
The question has has nothing to do with QRCode, but it explains the reason why I'm doing it.
ObjectId is a 12-byte BSON type, constructed using:
a 4-byte value representing the seconds since the Unix epoch,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
Once known that, it depends on the part of the objectId you choose and how many time will pass between the insertions.
Regards
Regardless of whether it's safe or not, the size difference between the QR codes isn't that great.
Using the full string will get you an image like:
Using half the characters produces a code like:
I would suggest that even the cheapest smartphone would be able to scan the larger of the two images - it's not very complex at all.
Yes, you can safely compress a long hexadecimal string into a higher base to get fewer characters while retaining the same value.
Example:
Hex: 52d35bf26bda8a5c8f8a22a8
Base64: UtNb8mvailyPiiKo
The same idea can be taken further by using binary or even Chinese pictograph characters instead of base64.
This concept can be tested using a Numeral Base Converter Tool.
In a SOAP app, all communication with the server is as text, when the server needs an integer it is the text value that gets sent and returned integers are sent back as text.
To have the app working with integers one has to convert the returned strings into numbers e.g. NSInteger but then to, for example, save them to an array they must be objects (NSNumber) but then whenever the numeric value is needed you have to extract it so is it better to leave all number based variables as NSStrings & only extract the numeric value if needed?
Basically my question is, in a soap app, isn't it simpler to just have all variables as NSStrings? Since they are similar to NSNumber objects in terms of usage and leaving all numbers as strings at least saves having to convert back & forth whenever there is server communication involved.
Storage of an integer in an NSNumber will likely have lower overhead — however minimal it might seem — compared with an NSString. A character string can be multiple bytes per glyph depending on the character encoding, and then you need a null character at the end of the string to terminate it.
A parser has to work through all of that to turn a string back into an integer at the end of the day, such as when you will inevitably need to do arithmetic on these values.
Further, using NSNumber will make it clearer to you what primitive data type you are working with from the SOAP request or response, not only when you write your app, but when you come back to it several months down the line and you need to make changes.
What is the allowed format for PayPal's Website Payments Standard (WPS) forms in the "amount" field? Must the decimal point be ".", or is it currency-dependant? Must there always be exactly two decimal places, or can there also be three (for currencies that have such small nominations) or none (for currencies that have hyper-inflation)?
I know that this should be a question for PayPal's documentation/forums, but the first has a vast room for improvement (to say the least) and the second is as speedy as a sleeping snail. I have posted a question there, but I don't expect any replies sooner than about two weeks. Hopefully someone here will have an idea.
Looks like it's not currency dependent and the API is expecting at most two (2) decimal places with a period separator.
amount
[...] Limitations: Value must be a positive number. No currency symbol. Must have two decimal places, decimal separator must be a period (.), and the optional thousands separator must be a comma (,).
Website Payments Standard Button Manager API Overview