4 ms·
> Not Good For: > User IDs - Can be decoded, revealing user count Suppose you don't want to leak the count, what's a resonable way of implementing that? You
by filleokus 3y ago
> Not Good For:
> User IDs - Can be decoded, revealing user count
Suppose you don't want to leak the count, what's a resonable way of implementing that?
You can of course have a uuid v7 / uulids or something as the primary key. Or have it as a public facing primary key, mapping back to a sequential ID PK (there might be some performance hits with larger PK's in e.g postgres? or is that just fud?)
But you could also generate a public ID with something like encrypt(seq_id, secret) and then encode it with whatever alphabet and or profanity filter you'd like - right? The issue then is that all public ID's would be long (and of course dealing with a decrypt operation on all incoming requests).
Don't know what's best really.
- 8n4vidtmkvmk 3y agoAdd an offset, multiply by a large prime number, and modulo. I don't think you can recover the original number without figuring out the prime.
- filleokus 3y agoAh, that's neat. Why is the offset necessary?
- erhaetherth 3y agoMight not be, but I like to start with a big number instead of 0 or 1 to fill all the bits. For example, if your prime is 100019, then your first number in binary is 00011000011010110011 but if your max number is something like 2^53 (00100000000000000000000000000000000000000000000000000000) then you have a lot of unfilled bits. The way I have mine set up, the output ID is always exactly 9 chars. 99% of the time it's naturally 9 chars because just by probability most of the numbers will be large, but some of them come out 8 chars and then I just pad up to 9 so it's nice and consistent.