←back to thread

Klarna users are being signed in to random accounts

(twitter.com)
475 points danielstocks | 1 comments | 27 May 21 10:28 UTC | HN request time: 0.218s | source
Show context
henvic ◴[27 May 21 15:07 UTC] No.27304014[source]▶
As a software engineer, I hate when I add a check for something "that will never happen" but that if happens is awful, and people complain.

A classic example: you need to get a user from a session, check against a database, and continue if they're signed in.

Then I add a simple if databaseUser.Username != form.Username and people will say "if that happens we've something worse wrong". Geez, something might be wrong and such double checking might provide to be useful.

On a smaller scale, bits flip due to cosmic rays and so on. Of course, there must be a limit where we stop, but people are used to actively avoid doing such "silly assertions" even for important steps.

¯\_(ツ)_/¯

replies(9): >>27304123 #>>27304382 #>>27304569 #>>27304654 #>>27304687 #>>27304894 #>>27308296 #>>27308719 #>>27309906 #
1. jojohohanon ◴[27 May 21 16:06 UTC] No.27304654[source]▶
A lifetime ago I was writing code for airline data processing. The specs are very clear about what the valid representation of every field was (less so about what they meant, but...).

So we generated our parser to fail if field ORG/1457 (made up) was not numeric max 8 digits. Or missing where mandatory.

Even if we never touched the data in that field.

Turns out that no-one else used the spec that way. No two were the same, so we had to basically implement two layers of parsing. One to put the data in a common parse tree, and the other to per-sending-mainframe interpret the data as how the sender had implemented.

We assumed that the mainframe would never send illformed data, and indeed that-could-never-happen. But they differed in what they thought was well formed.