70db6314e3
Images were readable by any signed-in user, not just their owner. Keys are now namespaced per user in both shapes the app writes, the three bar/ objects that predated that were migrated under the owner's prefix, and the image route enforces the prefix - answering 404 rather than 403 so it does not confirm someone else's key exists. Barcode-mirrored images now write under the user prefix too. deleteImage existed but was never called, so deleting a drink, bar item or scan removed the row and left the file in storage forever, still fetchable. All three now clean up through one shared helper, after the database work and best-effort, so a storage hiccup cannot block a delete the user asked for or leave the row behind. Menu scans are processed detached from the request, so every deploy abandoned anything in flight and left the row PROCESSING forever with a spinner that never resolved. They are now reaped lazily when a user lists their scans - no scheduler needed. Concurrent extractions are capped at two per process: each is a vision call with a four minute timeout that costs real money, and nothing else bounded them. MenuItem gains userId. Ownership was only ever transitive via scanId, which held because nothing queries MenuItem directly, but left any future direct query an IDOR with nothing to stop it. Restore was correctly scoped but unbounded, so a crafted file could create unlimited rows in one transaction against shared Postgres - self harm with one user, denial of service with several. Capped, and imageUrl from the CSV now goes through the same validation the API enforces instead of reaching the column unchecked. Members can delete their own account and data. Once the app holds other people's history, including Rating.location, that is the minimum. Registration rate limiting took the first x-forwarded-for hop, which the client controls; it now takes the last, which our proxy appends. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6.3 KiB
6.3 KiB