JP 70db6314e3 Phase 5 hygiene: image ownership, real deletes, scan resilience
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>
2026-08-08 21:57:57 +00:00
2026-08-08 20:42:40 +00:00
2026-08-08 20:42:40 +00:00

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.

AI Gateway (Switchboard)

All AI features — menu scanning, label identification, drink search, the bartender and the recommendation engine — go through Switchboard, an OpenAI-compatible gateway that routes each request to the best available model. The app never pins a model id; it always sends switchboard/auto and lets the gateway choose, then logs which model answered and what it cost.

Setup:

  1. Set SWITCHBOARD_BASE_URL in your env file (defaults to http://192.168.2.11:8787/v1).
  2. Mint an API key in the Switchboard UI under Settings → API keys.
  3. Add that key in the app under Settings → AI Gateway.

Per-feature routing (cost/quality levers, token budgets, timeouts) lives in src/lib/ai/routing.ts. Note that a Switchboard key carries its own routing defaults, so the app sets category and prefer_free explicitly on every request rather than inheriting whatever the key was minted for.

Migrating from the old Claude/OpenAI integration

Earlier versions stored a per-user Anthropic or OpenAI key. Those rows are ignored at runtime and the Settings page offers to remove them, so no migration is required. To clear them in bulk instead:

DELETE FROM "UserApiKey"  WHERE provider IN ('claude','openai');
DELETE FROM "SearchCache" WHERE provider IN ('claude','openai');
UPDATE "UserPreference" SET "defaultProvider" = NULL;

Learn More

To learn more about Next.js, take a look at the following resources:

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more details.

Description
No description provided
Readme 1.1 MiB
Languages
TypeScript 96.5%
Shell 2.9%
JavaScript 0.3%
CSS 0.2%
Dockerfile 0.1%