Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@martygeek how would you fix it to remain secure?
-
@ThermalCube think of it like a computer would: a raw sequence of digits with no collective meaning, then it makes sense.
-
@demortes exactly I could easily times both numbers by 0 and fix their issue but that would leave the possibility of duplicate record lookups, so not secure. There are 500+ clients I really don’t want to add
If(dumbclient){
}else{
} -
@demortes I'd give you the answer but you're the one billing, not me. That's what you're paid for - to figure it out
-
@martygeek basically you don't know. I'm paid nothing cause I'm not OP. 123 is different from 0123. To accept 123 or 0123 for the same person while not actually being the same person means its insecure and inaccurate. I don't think there's a way to fix it without printing new badges. Or if the badge transmits something else entirely in addition to. Grab a second piece of info and compare. Not as secure but you avoid the original inaccuracy.
Client support ticket: we printed the ID cards without leading 0’s can you fix it with software?
Me: unfortunately we cannot because the ID number can be any length. ID 123, 0123 and 00123 can exist. What barcode would 123 go to?
Client: this is ridiculous we will cancel our contract.
Me: i’m sorry we can’t correct for a mistake on your end.
(Side note: I know allowing 0123 and 00123 is dumb but my team didn’t design the business logic)
rant