Accounts people can create, and photos on a server with no bucket
A tenant had exactly the users somebody had created with a command on the
server. That is not a missing screen: a shop with an owner and four staff
either shared one password or raised a ticket per person, and a phone app
for the shop floor could not exist while there was one account to sign in
as.
Registration is by invitation, never open signup - the same line already
drawn around creating a company. The code carries the address and the role
and the request carries only a password, so a code that gets forwarded
cannot become somebody else's account, and a staff invitation cannot be
redeemed as an owner. Single use lives in the UPDATE and the account is
created in the same transaction.
Deactivating a member revokes their sessions in that transaction too. An
access token lives twelve hours, so without it "remove their access"
removed it sometime tomorrow. The session list and revoke that go with it
are the benefit of opaque tokens the product had been paying for and never
collecting: nothing could say what was signed in, let alone stop one.
Face images now work on a deployment with no object storage, which was
every local install and every self-hosted site - the arrivals feed said
"not storing customer photos" for every customer forever, on the screen
whose whole job is to show a face. Bounded to one row per visitor, so it
grows with the customer base and not with footfall; the bucket stays
primary wherever one exists.
Image.auth says whether a URL needs the session, because a browser img
cannot load one that does, a mobile image view can, and a webview can do
neither - the desktop client resolves those to a data URI in Go.
Found by running it, not by tests:
* UPDATE ... RETURNING gives the value AFTER the update, so the prune
read back empty keys, deleted nothing, and the table grew with
footfall exactly as if it were not there. The fake agreed with either
version; only the live Postgres test caught it.
* Trusting only the auth flag broke every shop card, because Sites.jsx
rebuilt a partial snapshot object and dropped it. A relative URL is
now sufficient on its own.
* ago() renders a future time as "just now", so a code valid for a week
read "expires just now".
Verified live against real Postgres: invite, preview, escalation refused,
register into a session, replay 404, staff forbidden, device revoked and
401 at once, last owner refused, and a 92,405-byte camera JPEG stored,
served to its owner, 401 with no session, 404 to another tenant, and
rendered in a browser.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HViLj9gYNRtSr7YVZmW5sn
This commit is contained in:
@@ -122,6 +122,23 @@ async function fetchImage(path, retry = true) {
|
||||
parsed?.message || `That picture could not be loaded (${res.status}).`)
|
||||
}
|
||||
|
||||
// A label for the session list, so somebody can tell which device to sign out.
|
||||
// Deliberately coarse and never an identifier: a fingerprint here would be a
|
||||
// tracking signal we have no reason to hold, and the question this answers is
|
||||
// only "which of these is the one in my hand".
|
||||
function deviceName() {
|
||||
const ua = navigator.userAgent || ''
|
||||
const os = /Windows/.test(ua) ? 'Windows'
|
||||
: /Mac OS X|Macintosh/.test(ua) ? 'Mac'
|
||||
: /Android/.test(ua) ? 'Android'
|
||||
: /iPhone|iPad/.test(ua) ? 'iOS' : 'Unknown'
|
||||
const browser = /Edg\//.test(ua) ? 'Edge'
|
||||
: /Chrome\//.test(ua) ? 'Chrome'
|
||||
: /Safari\//.test(ua) ? 'Safari'
|
||||
: /Firefox\//.test(ua) ? 'Firefox' : 'browser'
|
||||
return `${browser} on ${os}`
|
||||
}
|
||||
|
||||
const qs = (params) => {
|
||||
const p = new URLSearchParams()
|
||||
for (const [k, v] of Object.entries(params || {})) {
|
||||
@@ -136,7 +153,7 @@ export const api = {
|
||||
const res = await fetch('/api/auth/login', {
|
||||
method: 'POST',
|
||||
headers: { 'Content-Type': 'application/json' },
|
||||
body: JSON.stringify({ email, password }),
|
||||
body: JSON.stringify({ email, password, device: deviceName() }),
|
||||
})
|
||||
const body = await res.json().catch(() => null)
|
||||
if (!res.ok) {
|
||||
@@ -147,6 +164,39 @@ export const api = {
|
||||
return body.user
|
||||
},
|
||||
|
||||
// What a code says it is for, before anybody is asked to choose a password.
|
||||
// Unauthenticated by necessity: the holder has no account yet.
|
||||
async previewInvitation(code) {
|
||||
const res = await fetch('/api/auth/invitation' + qs({ code }))
|
||||
const body = await res.json().catch(() => null)
|
||||
if (!res.ok) {
|
||||
throw new ApiError(res.status, body?.error || '',
|
||||
body?.message || 'That invitation code is not valid.')
|
||||
}
|
||||
return body
|
||||
},
|
||||
|
||||
// Redeem an invitation. Returns a signed-in session, not just an account:
|
||||
// sending somebody who has just chosen a password to a sign-in form to type
|
||||
// it again is the sort of thing that gets blamed on the password.
|
||||
//
|
||||
// The address and the role are NOT sent - they come from the invitation, and
|
||||
// the server refuses a body that names either.
|
||||
async register({ code, full_name, password }) {
|
||||
const res = await fetch('/api/auth/register', {
|
||||
method: 'POST',
|
||||
headers: { 'Content-Type': 'application/json' },
|
||||
body: JSON.stringify({ code, full_name, password, device: deviceName() }),
|
||||
})
|
||||
const body = await res.json().catch(() => null)
|
||||
if (!res.ok) {
|
||||
throw new ApiError(res.status, body?.error || '',
|
||||
body?.message || 'Could not create the account.')
|
||||
}
|
||||
setTokens(body.access_token, body.refresh_token)
|
||||
return body.user
|
||||
},
|
||||
|
||||
async logout() {
|
||||
try { await send('POST', '/api/auth/logout') } catch { /* already gone */ }
|
||||
clearTokens()
|
||||
@@ -196,6 +246,25 @@ export const api = {
|
||||
|
||||
clients: () => send('GET', '/api/admin/clients'),
|
||||
createClient: (input) => send('POST', '/api/admin/clients', input),
|
||||
|
||||
// The people who work here.
|
||||
team: () => send('GET', '/api/team'),
|
||||
updateMember: (id, changes) =>
|
||||
send('PATCH', `/api/team/${encodeURIComponent(id)}`, changes),
|
||||
invitations: () => send('GET', '/api/team/invitations'),
|
||||
// The code comes back in full exactly once - only a hash is stored - so
|
||||
// whatever calls this has to show it there and then and must not expect to
|
||||
// read it back later. Same contract as enrolmentCode above.
|
||||
invite: (input) => send('POST', '/api/team/invitations', input),
|
||||
revokeInvitation: (id) =>
|
||||
send('DELETE', `/api/team/invitations/${encodeURIComponent(id)}`),
|
||||
|
||||
// Devices this account is signed in on. The point of holding sessions in a
|
||||
// table rather than issuing JWTs is that signing one out actually works.
|
||||
sessions: () => send('GET', '/api/auth/sessions'),
|
||||
revokeSession: (id) =>
|
||||
send('DELETE', `/api/auth/sessions/${encodeURIComponent(id)}`),
|
||||
signOutOthers: () => send('POST', '/api/auth/sessions/revoke-others'),
|
||||
}
|
||||
|
||||
// The live stream, read with fetch rather than EventSource.
|
||||
|
||||
Reference in New Issue
Block a user