The deployed bundle shipped with no API base URL, so every request fell back to
a relative /api/*, which the frontend's nginx forwards to a backend:8000 service
this deployment does not have.
The cause was this Dockerfile. Vite gives a real environment variable precedence
over its .env files, so `ARG VITE_API_BASE_URL=""` followed by `ENV
VITE_API_BASE_URL=$VITE_API_BASE_URL` did not leave the value unset - it set it
to an empty string and overrode .env.production. Nothing about the build says
so; it just quietly produces a bundle with no API host.
Reproduced directly: building with VITE_API_BASE_URL="" in the environment
yields a bundle with no API URL, and building with the variable unset bakes in
https://mcp.nearle.ai.in from .env.production.
The value now comes from .env.production alone. Point a build elsewhere by
editing that file or adding .env.local; both are read by Vite and neither can be
silently empty.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The deployed bundle had no API base URL baked in at all, so the app fell back to
relative /api/* requests, which the frontend's nginx forwards to a backend:8000
service that does not exist in this deployment.
Same cause as the backend: Dokploy writes its own .env into the build context
from the service's Environment tab after cloning, and that tab is empty, so the
committed file was replaced by a zero-byte one. The checkout showed .env at 0
bytes, and grepping the running container's bundle for the API host returned
nothing.
Vite loads .env.production for production builds and it takes precedence over
.env, so the config now travels under that name and survives. No Dockerfile
change is needed - Vite resolves it natively - and the --build-arg stays
unnecessary.
Verified by writing an empty .env over the checkout, exactly as Dokploy does,
and building: https://mcp.nearle.ai.in is still inlined into the bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
