VITE_API_BASE_URL is inlined into the public JS bundle at build time, so it is
readable by anyone who opens the site. Ignoring it protected nothing and only
meant the value had to be remembered and re-passed as --build-arg on every
deploy - which is exactly how the bundle ended up pointing at a host that did
not exist.
Vite reads .env during `npm run build`, so the Docker build now picks the domain
up on its own and needs no build arg. Verified: a build with no --build-arg
bakes in https://mcp.nearle.ai.in.
.env.local stays ignored for local overrides. Nothing secret belongs in a
VITE_-prefixed variable - it would be published in the bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The API deployed to mcp.nearle.ai.in rather than mcp.catalogue.nearle.ai.in.
This matters more here than on the backend: VITE_API_BASE_URL is inlined at
build time, so a bundle built from the old value calls a host that does not
exist and every request fails with nothing in the server logs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Admin-only page at /mcp showing the server's connection details, a
copy-pasteable client config, and every tool with its arguments - plus a console
to run one against live data and see what an AI client would get back.
It talks to /api/mcp/*, not to the /mcp endpoint directly. That endpoint speaks
streamable HTTP with session handling, and implementing a client for it in the
browser purely to render a tool list would be a lot of machinery for a read-only
admin screen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Seven call sites used fetch() directly instead of the api client in
src/api/client.js, so they sent no Authorization header. Four of them hit
endpoints the backend guards with a permission, and every one of those returned
401 for any signed-in user:
AdminPage /api/admin/training/upload-dataset (upload_train_test)
AdminPage /api/admin/training/allocate-discounts (allocate_discounts)
UserPage /api/user/products/add (add_product)
UserPage /api/user/products/upload-file (upload_batch_products)
The remaining three hit public GETs and worked, but bypassed VITE_API_BASE_URL
and the central 401 handler just the same.
Route all seven through the client and add the endpoints it was missing.
Multipart uploads still need a raw fetch, because the browser has to set its
own Content-Type to carry the boundary, so that is now one upload() helper that
attaches the auth header and routes 401s to the logout handler rather than
three copies that did neither.
handleAllocateDiscounts only acted on res.ok, so a 401 or 403 left the panel
looking idle with no indication that nothing had been allocated. It surfaces
the error now.
Take VITE_API_BASE_URL as a Docker build arg. The app is served from
catalogue.nearle.ai.in and the API from mcp.catalogue.nearle.ai.in, and Vite
inlines env vars at build time, so setting this on the running container does
nothing - it has to reach npm run build. Defaults to empty, which keeps
requests relative for the same-origin nginx proxy.
Also revoke the object URL after the sample-CSV download.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
