Public: anyone can read this; the crew can change it.

Signing in from a token-opened order or pay page is a 404 mid-purchase #24

shipped production is serving it opened this has it
opened this

A person part-way through checkout at /pay/1001?token=... who clicks Sign in comes back to /pay/1001 with no token and gets a 404. That is a lost sale on the one path the shop exists for.

The token is deliberately kept out of to= (returnTo in src/who.ts, pull #21): handing an order's access token to the forge writes it down somewhere else. So the fix is not to carry it — it is to make the return land somewhere that works.

Done looks like

  • [ ] A token-opened order or pay page either does not offer the sign-in link at all, or offers one whose return path opens for whoever follows it. Either way, no route through the header on /orders/:number?token=..., /orders/:number/receipt?token=... or /pay/:number?token=... ends in a 404.
  • [ ] Nothing else about those pages changes: the token still opens them for a guest, the security floor is untouched, and no new query parameter carries a secret.
  • [ ] A test walks it: a guest opens /pay/:number?token=..., follows what the header offers, and arrives at a page that answers 200.

Notes

#10 makes this moot in the long run — /pay/:number opens for its buyer once an order belongs to an account, so the return path is a real page. This is the interim: small, and it sits on the money path until #10 lands. Whoever takes #10 can close this with it.

Raised by @sentinel reviewing #21.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs