JakeBreath
a93500154c
Replaces the build-time VITE_API_BASE knob with a runtime setup screen so one build works same-origin and cross-origin: - frontend/src/lib/backend.ts stores the API origin in localStorage (empty = same origin). DEFAULT_BACKEND_URL is the clearly marked, easily edited prefilled default — the matrix.org equivalent; set it to your public API origin. - Production builds show /setup before anything else on first start, with a connection test against /health (or leave it blank for this server). The route stays reachable from Account -> Backend connection; switching backends clears the previous backend's token and reloads. - Input normalisation: scheme defaulted (https, http for localhost), trailing slashes trimmed; a failed cross-origin test points at CORS_ALLOWED_ORIGINS. - Dev keeps defaulting to the same-origin Vite proxy; /setup can be visited manually. Verified: normalisation cases in Node, /health returns CORS headers for an allowed origin, tsc/oxlint/build clean.
46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
Use the venv on backend/venv/
|
|
|
|
DO NOT mess with the system's python
|
|
|
|
For Frontend work:
|
|
|
|
read both Frontend Design related Markdown files on the frontend/ folder
|
|
|
|
For anything touching e621 endpoints or payloads (posts, pools, tags, users,
|
|
favorites, IQDB, blacklists, uploads), consult the e621 OpenAPI spec first:
|
|
https://e621.wiki/openapi.yaml
|
|
|
|
Download it once per session (it is ~450 KB YAML), then grep it for the exact
|
|
path/parameter/schema names instead of guessing:
|
|
|
|
curl -sL https://e621.wiki/openapi.yaml -o /tmp/opencode/e621-openapi.yaml
|
|
grep -n "^ /pools.json" /tmp/opencode/e621-openapi.yaml
|
|
|
|
Notes learned from the spec (verify before trusting):
|
|
- Index endpoints often return a bare array (e.g. GET /pools.json) while the
|
|
show endpoint returns the object directly (e.g. GET /pools/{id}.json) — not
|
|
always wrapped in a named key.
|
|
- Pools index supports search[order] (id_asc, id_desc, name, created_at,
|
|
post_count), search[name_matches], search[category], search[is_active].
|
|
- Own settings (including user[blacklisted_tags]) are updated with
|
|
PATCH /users/{id}.json as form-encoded data; /users/me.json returns the user
|
|
object at the top level.
|
|
|
|
Project constraints (do not regress):
|
|
- Backend is Django 6 + DRF with token auth (no session auth on the API);
|
|
MariaDB/Redis come from docker-compose.yml.
|
|
- Deployment will be Docker-based (compose); do not add systemd/cron unit
|
|
files for scheduling — use the container setup for timers/workers.
|
|
- Same-origin and cross-origin frontends both work: a production build asks
|
|
for the backend origin on first start (/setup, stored in localStorage;
|
|
DEFAULT_BACKEND_URL in frontend/src/lib/backend.ts is the prefilled
|
|
default), the backend allows extra origins via CORS_ALLOWED_ORIGINS (plus
|
|
CSRF_TRUSTED_ORIGINS for the admin), and API media URLs are absolute
|
|
(built from the request host), so signed files load cross-origin too.
|
|
TRUST_PROXY_HEADERS=true is required behind a TLS-terminating proxy.
|
|
- No server-side media processing: the home server cannot handle it.
|
|
Compression/optimization runs client-side (WebCodecs + WASM in a worker)
|
|
and the server only applies the result via POST /api/files/J-x/optimize/.
|
|
- Do not use imgdd; perceptual hashing is imagehash server-side.
|
|
- Chat/messaging features are out of scope.
|