Show a code on the till so a phone can be pointed at this shop - #502
Merged
Merged
Conversation
Setting up a staff handset meant typing an address, and the person holding the phone is the one who does not know it. The owner knows the shop code; a waiter five minutes into their first shift does not, and had no way to find out. So the till shows a code and the phone reads it. GET /pair renders a printable page with a QR for every address a phone could actually reach this machine on. The Captain app already scans it. Which address goes on the code is the whole substance, and getting it wrong is invisible here: the page renders a perfectly good QR for an address the phone cannot reach, and it surfaces minutes later on somebody else's handset as "cannot find the shop". A till opened locally sees localhost:5555 in its own address bar, and a phone pointed at localhost is pointed at itself - so the addresses come from the network interfaces, not from the request, Wi-Fi first because a till is often wired and wireless and the phone is on the wireless one. A shop reached at a public address gets that instead, because it keeps working away from the shop. The decision lives in api/src/utils/pairing.js with no dependencies, so it is testable without express, qrcode or a running server. Public on purpose, and declared as such in public-routes.test.js: the code carries an ADDRESS, not a credential - the same thing the till's own address bar shows anybody standing at it. Requiring a login would mean a handset cannot be paired until somebody signs in on the till, which is backwards, since pairing is what happens before anyone can. Uses the qrcode package the API already depends on. No new dependencies.
The CI lint job runs prettier --check over api/src. ESLint was already clean; this is whitespace only.
Contributor
|
Merged to Try it at https://develop.posnic.io, or run it yourself: git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev # then http://localhost:3000When you have tested it, say what you did and what happened, and set Reporting that something is broken is as useful as fixing it. It is |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Setting up a staff handset meant typing an address, and the person holding the phone is the one who does not know it. The owner knows the shop code; a waiter five minutes into their first shift does not, and had no way to find out.
So the till shows a code and the phone reads it.
GET /pairrenders a printable page with a QR for every address a phone could actually reach this machine on. Captain already scans it.Which address goes on the code
That is the whole substance, and getting it wrong is invisible here: the page renders a perfectly good QR for an address the phone cannot reach, and it surfaces minutes later on somebody else's handset as "cannot find the shop".
localhost:5555in its own address bar, and a phone pointed at localhost is pointed at itself. So addresses come from the network interfaces, not from the request.The decision lives in
api/src/utils/pairing.jswith no dependencies, so it is testable without express, qrcode or a running server. 8 tests cover it.Public on purpose
Declared in
public-routes.test.jswith a reason, which is what that test is for. The code carries an address, not a credential - the same thing the till's own address bar shows anybody standing at it. Requiring a login would mean a handset cannot be paired until somebody signs in on the till, which is backwards: pairing is what happens before anyone can.Notes
qrcodepackage the API already depends on. No new dependencies.docs/API.md,docs/openapi.jsonand the README endpoint count regenerated, as the docs gate requires.develop: same failures before and after, plus 8 new passing tests.