8d7139b03136868514b1c9a8bab7c42fc996f3d3
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Alexander Heldt
|
66f89b35a9 |
Keep showing a guest link's URL so it can be copied again
The URL was shown once, in a box under the create button, and then gone: only a hash of the token was stored, so the app genuinely could not produce it a second time. Lose the message you sent the sitter and the only way back was to mint a new link — which strands whoever is already holding the old one. Settings now lists every live link with its URL and a Copy button, so re-sending one is just copying it again. That means keeping the token rather than only its hash, and it is worth being plain about the trade. It is not the trade you would make for a password, which the user has probably reused, or a session token, which grants everything indefinitely. A guest link grants a strict subset of what the same database already holds in plaintext, expires on a date the owner picked, and can be revoked in one tap — so an attacker who can read puppy.db gains very little by also being able to open it as a guest. The lookup column stays a hash and remains the key redeem matches against; the secret sits in a new column beside it, which also keeps the migration additive. Links created before this have an empty secret. They keep working and stay revocable — the migration touches nothing but the new column — and the list says why their URL is missing rather than rendering a broken one. The two tests that asserted the old contract now assert the new one: a listing hands back a secret that really opens the link, and the lookup column is still a hash. Added one for the legacy row, since "still works, just cannot be shown" is the part a future change is most likely to break quietly. |
||
|
Alexander Heldt
|
da68b733e4 |
Let a day be left out of the stats
Every logged day was treated as equally trustworthy, and they aren't. A day someone else had the puppy leaves a thin record that reads exactly like a real one — five hours of sleep, two pees, no walk — and then drags down the average, widens the longest gap in the Timing panel and puts a trough in every chart that never happened. "Not counted", in the overview panel's heading, takes the day you are looking at out of everything that aggregates across days. Nothing is deleted or hidden. The day's own overview, history and sleep & wake list are exactly as they were, dimmed and labelled; navigate to it and it is all still there. Only the cross-day views stop seeing it, and weight and notes keep counting wherever they fall — a weigh-in and a vet note are facts you recorded, not behaviour a sparse logger distorts. The mark is an ordinary event, the way a training session is. That was the whole reason to do it this way: a set of marks that sync per-item with last-write-wins and tombstones is exactly what the event contract already provides, so un-marking is a delete, offline works, and two devices marking the same day resolve themselves. An excluded_days table would have meant a table, an endpoint, a request/response pair and a client cache to re-derive semantics already in hand. Every renderer selects events by type, so a new type is inert everywhere it isn't wanted; only the History log has to filter it out, being the one view that shows whatever it is handed. render() already computed the event list once and fanned it out, which made the seam a single place: day-scoped panels keep the full list, weight and notes keep it too, and the seven cross-day renderers take a counted one. Filtering alone gets two things wrong, and those are most of the diff. An empty slot lies. A marked day with no events draws a zero bar, which reads as "the puppy barely slept" — precisely the misreading the mark exists to prevent. So weeklyData zeroes the day's figures and flags it, and the four bar charts, both actograms and the training grid paint a hatch in the slot instead. Zeroing centrally rather than in each chart means every axis maximum, total and tooltip downstream is already right. The slot stays: dropping it would make consecutive bars stop being consecutive days. Gaps balloon. gapsBetween subtracts consecutive events, so with a day's events gone Tuesday's last pee sits next to Thursday's first and the subtraction invents thirty hours — worse for the panel than the sparse day ever was. Any gap whose interval touches a marked day is therefore discarded rather than measured. Sleep and walk durations need no such care: sleepMsInRange and walkMsInRange already clip to the day being measured, so a nap running in from a marked day contributes only its counted part. Both trend charts skip marked days explicitly rather than leaning on their existing "any sleep at all" guard, which would have let a nap crossing midnight give a marked day a non-zero total and sneak it back into the average. Owner-only, alongside the rest of what a guest may not decide: a sitter should not be able to rule their own thin day out, nor quietly take a good one out of the averages. The server drops day-excluded events arriving on a guest session; the client hides the control to match. |
||
|
Alexander Heldt
|
e22031ed4f |
Add guest links for temporary shared access
Handing a dog sitter the ability to log a pee meant handing them the account password: permanent, total control, revocable only by changing it. Settings → Guest access now mints a URL that does the one thing instead. A link is a session, not an account. Opening /guest/<token> inserts an ordinary session row against the owner's user_id, tagged with the link it came from, so every data path downstream — sync, photos, the profile — stays scoped by user_id exactly as before and needed no changes at all. Only the capability checks differ by role, which is what kept this from touching the sync contract. Redemption is a plain GET so tapping the link in a message works, and the 303 to / leaves the token out of the address bar, bookmarks and the PWA start URL. What a guest cannot change is enforced in the upsert, not in the UI. The WHERE clause gains a logged_by_share test: an owner (empty share id) may change anything, a guest only rows carrying their own link's id. A sitter can fix up their own entries and cannot rewrite or delete one of the owner's, including everything logged before this existed, since those rows carry the empty id too. Deletes come along free, being tombstones. The test is on the link id rather than its label because two links can easily both be "Sitter", and the id is also why /api/me hands the guest its share id: the client needs it to know what to grey out. The exercise library is the owner's on the same reasoning — a guest trains against it but the server drops any exercise a guest sends. Attribution is stamped from the session on insert and left out of DO UPDATE SET, so it is decided once by whoever logged the event and survives every later edit. It never comes off the wire, so it cannot be forged — a guest re-POSTs the owner's whole event list on every sync, but those rows already exist and keep their stored values. Expiry is a date the owner picks; the link dies at the end of that day in their own timezone, which the client computes because the server has no way to know it. Sessions are capped at the link's own end, and every request re-checks the link is live rather than trusting the session row, so revoking kicks a guest out on their next request instead of whenever their session happens to lapse. Only the token hash is stored, as with session tokens, so the URL is shown once at creation and cannot be read back. The client side follows from that. A guest opening someone else's entry gets the edit dialog read-only rather than a form that would silently discard what they typed, and mergeSynced takes the server's copy for anything they may not change — otherwise a refused write would sit in their cache forever showing an edit that never happened. An ended link wipes their cached copy of someone else's history and says so, rather than offering a sign-in form they have no password for. |