A bot logged into my app before my friend could
Found it before an appointment. Fixed it on the drive. Shipped it in the waiting room.
Receiving a message from a friend (and former work colleague) telling you they can’t access the system you built sucks. The kind of suck that one wishes there was a rock I could crawl under. I might be milking the scene a bit for dramatic effect, but it still sucks, no one likes to hear they have a problem.
That’s what happened to me today.
“Hey Kevin, I signed up for your service, but I can’t login. Here’s my email address I’m trying to log in with and the device/browser I’m using. Can you help?”
I had 10 minutes before Charlotte and I were to head out for an appointment, so the pressure was on.
Check the logs, yep, there were the three login attempts made. But no indication of an error in the process nor that they received the message saying the magic link the app sent them to failed.
This was going to require intuition and an educated guess.
The difference in the time that the token was created and the time it was used was only a dozen seconds. That seems quick, too quick.
An AI prompt later, the working theory was developed. Somehow, the token for the magic link was already used before my friend could click the link in the email. But, why?
AI had an idea. I didn’t, this was outside of any experience level. I’ve been around a lot of systems in my career, but authentication and authorization mechanisms was an area I didn’t spend a lot of time in.
The most likely cause was that an email security scanner/pre-fetch was loading the link in the email and because the way the /auth end point was written, it was validating the token with the pre-fetch which in turn told the system that the token was valid, and no longer needed and discarded.
That all happened between the email being delivered and the time my friend clicked the link. When they clicked the link, they received the unfriendly message that they couldn’t login.
And to add insult to injury, there was no way in the app for them to reach out and ask for assistance. Luckily, they had my number.
This was the theory, it was easily tested and confirmed.
The fix is simple, don’t validate the token when the /auth end point is called. Instead, put an intermediary step requiring the user to click the link in the email, load a new page with another button to select to finish the login process.
Yes, the solution adds a bit of friction to the process, there’s an extra click now. But, it eliminates any pre-fetch or inadvertent previewing of the page assuring that the token will work when the user intends it to work.
So, the embarrassment is real, I have no way of knowing how many other people have had the issue, more than I’m willing to admit to b/c I can see the similar usage patterns.
The embarrassment was replaced with gratitude quickly b/c someone took the time to say, something wasn’t right and brought it to my attention.
This isn’t about not trusting what AI builds. That’s too easy, and it sidesteps the real responsibility. I understood the design. What I didn’t have was the experience to know there was a gap in it. And building alone means there’s no one else around to catch what you don’t know to look for.
The counter to that is building a system that expects surprises and handles them gracefully. For me, that means an easy way for someone to reach me when something breaks, and auditing every critical process that could stop a user dead and hardening those first.
What tips or techniques do you build with to handle the unexpected surprises that will inevitably hit your system?