Flow
Each convenience and what pays for it
1Lasts for years
Paid for by the dev-only check, asked in more than one place.
2Works every time
Paid for by the stamp: only a row my script wrote accepts a short PIN.
3Wrong guesses do not count
Nothing makes the PIN harder to guess, so the fences limit who can reach it.
4Reset from the login page
Paid for by a route that says not found unless dev and a separate switch are on, plus an email list.
A one-time code, emailed, is how you log in to the ordering system. The dev copy can't send email. So I built a shortcut, made it weaker step by step, and fenced it in so it stays on the dev box.
How the shortcut got weak
A flag already let the dev box show the code on screen instead of mailing it. But that was still a normal code. It ran out, it locked after a few bad tries, and it worked once. I wanted a short PIN I set once and remember.
The first try was careful. A script set a short PIN on my account. It lasted a day and worked once. A few commits later, it lasted years, worked every time, and ignored wrong guesses. Then I put a reset button on the login page.
That's a short PIN that never runs out and never locks. A loop could guess it fast. So every fence below is about who can reach it. None of them makes it harder to guess.
One question, asked in three places
The box counts as dev when a dev or sandbox setting is on. The login check asks this before it will even look at a short PIN. The code that makes the PIN asks first and stops if the answer is no. The old show-the-code flag asks now too. If someone adds a new path later and forgets to ask, another check still catches it. But they all read the same setting, so if production ever gets that setting by mistake, they all open together.
A stamp only the script writes
The short PIN sits in the same table as normal emailed codes. When the script makes it, it clears my other unused codes and writes the new row with a special stamp. Nothing else writes that stamp. A short PIN only works against a stamped row. Try a short PIN against a normal code and you get the usual "wrong length" kind of error, so nobody learns a shortcut exists. And asking for an emailed code while a stamped row is there does nothing, so the login page can't bury it.
The rule is narrow.
A short input gets the ordinary wrong-length error unless this is a development process and the stored code carries the development stamp.
A route that acts like it isn't there
The route behind the reset button says "not found" unless the box is dev and a separate switch is on. After that, the email has to be on a list, the PIN has to be the right length, and unknown and disabled accounts get the same answer. There's no login on this route, on purpose. That's the price of getting back in when I'm locked out.
A fake database behind every test
Each fence has a unit test with a fake database. They check that short PINs fail off dev, the stamped PIN works and isn't used up, a wrong guess changes nothing, and the route stays hidden or says no. None of them run on a real build.
The right PIN that still failed
The first long-lived PIN didn't work, even typed right. The secret mixed into each PIN's hash was read once, when the code loaded. As best I can tell, the script hashed with one value and the server checked with another. Now the secret is read each time it's needed, and a test changes it after loading to prove the new value wins. My guess is the build froze the old value. The test shows the code reads late now. It can't tell me whether my guess about the build is right.