3 ms·
user-generated (as in: on the user's phone) was only at the very early stages of this product, and we've since moved to on-server. It's a cash-register type of
by mittermayr 5mo ago
user-generated (as in: on the user's phone) was only at the very early stages of this product, and we've since moved to on-server. It's a cash-register type of app, where the same invoice must not be stored twice. So we used to generate a fresh invoice_id (uuidv4) on the user's device for each new invoice, and a double-send of that would automatically be flagged server-side (same id twice). This has since moved on to a server-only mechanism.
The database flagged it simply by having a UNIQUE key on the invoice_id column. First entry was from 2025, second entry from today.
- bitsandbits 5mo agoIf the server or the user's phone had the wrong time and if the date is used in generating the ID...
- whatevaa 5mo agouuidv4 is random. uuidv7 includes time.
- tracker1 5mo agoAssuming the phone is using the default JS engine, it's whatever is being shimmed for node:crypto package's random bytes method... which is likely weaker. I wrote a different implementation that cheats by using browser's methods of getting a uuid. https://github.com/tracker1/node-uuid4/blob/master/browser.mjs https://github.com/tracker1/node-uuid4/blob/master/browser.m...