A waiter signs in once, not every day - #879
Merged
Merged
Conversation
Owner: "username password not saved already. everytime i need to enter." The handset was not forgetting. It stores the credential and stores it correctly. The credential expired. A till token lasting 24 hours is right: a till is a fixed machine behind a counter that somebody signs into at the start of a shift. A handset is not that. It is carried by a part-time waiter who was handed it five minutes ago and does not know the shop's password, so a daily expiry means finding somebody who does and bringing them over, at the start of every service, for every phone. One support call a day per shop, for ever, produced entirely by a number. So the handset gets its own lifetime, thirty days by default, and nothing else changes. signLegacyToken takes it as an optional last argument, so the till and the web sign-ins keep exactly what they had, and a test fails if a second caller ever picks it up by accident. WHY A LONGER ONE IS SAFE HERE AND NOT ON THE TILL. A lost handset is cut off by freeing its slot on the till, which the till already enforces and answers 403 to. That is a revocation a manager can actually perform. An expiry is not: it does nothing about the phone in somebody's pocket today, it only inconveniences the shop tomorrow. Still a number somebody can disagree with: HANDSET_JWT_EXPIRES_IN=24h brings the old behaviour back without a release, and a value somebody typed wrong falls back rather than throwing, because a waiter locked out by a typo in an env file has no way to find out what is wrong.
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
1 participant
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.
The handset was not forgetting. It stores the credential and stores it correctly. The credential expired.
A till token lasting 24 hours is right: a till is a fixed machine behind a counter that somebody signs into at the start of a shift. A handset is not that. It is carried by a part-time waiter who was handed it five minutes ago and does not know the shop's password, so a daily expiry means finding somebody who does and bringing them over, at the start of every service, for every phone.
One support call a day per shop, for ever, produced entirely by a number.
The change
The handset sign-in gets its own lifetime, 30 days by default. Nothing else changes:
signLegacyTokentakes it as an optional last argument, so the till and web sign-ins keep exactly what they had, and a test fails if a second caller ever picks it up by accident.Why longer is safe here and not on the till
A lost handset is cut off by freeing its slot on the till, which the till already enforces and answers 403 to. That is a revocation a manager can actually perform.
An expiry is not. It does nothing about the phone in somebody's pocket today; it only inconveniences the shop tomorrow.
Still a number somebody can disagree with:
HANDSET_JWT_EXPIRES_IN=24hbrings the old behaviour back without a release, and a value somebody typed wrong falls back rather than throwing, because a waiter locked out by a typo in an env file has no way to find out what is wrong.Tests
api/tests/unit/utils/a-waiter-signs-in-once-not-daily.test.js, 6 of them: a handset lasts longer than a day, the till is untouched, a shop can have the old behaviour back, a malformed setting falls back, the token and the number the phone is told come from one variable so they cannot drift, and no other sign-in was given the longer life by accident.864 util and middleware tests, and 2769 controller tests, all pass.
Note for other prompts
Per the slot book: this touches
api/src/controllers/users.controller.js,api/src/middleware/auth.jsandapi/src/utils/token-lifetime.js. I checked the open PR list first. #878 is the only one open and it touchessale.repository.js,sale.service.js, the sidebar and the payment modal, so there is no overlap. Claude4 is in the KOT-note area, which is also not these files.