mirror of
https://github.com/nestriness/nestri.git
synced 2026-09-19 09:15:19 +03:00
A single secret that turned any request into an operator was the only credential several routes accepted, and it had no caller left: the device pairing it existed for is on hold, and nothing in this tree or any client sent it. What remained was a key that bypassed authentication entirely, required to boot, and checked by nobody. Every route behind it had a better answer available: - Library and game sync move to host credentials. Both took a `userId` in the body, which meant one secret could write into anybody's library. A host now says which of its enrolled users a batch is for, and that claim is checked against the Steam sign-ins it actually holds — one box carries several people's accounts, so the pair is the unit. - Download-state reporting narrows to hosts alone, and the body that could name a different host is gone. Which host is reporting comes from its own credentials, and a body that still names one is refused rather than ignored. - Linking a Steam account is always for the caller. - Creating a game by hand is deleted; syncing already upserts the catalogue. - Reading the waitlist is deleted. Every address on it belongs to someone who has not agreed to anything, and answering it over HTTP made that list something a leaked key could drain. - The pairing-code routes are deleted with the flow they served. The domain module and its table stay, so returning to it is a route file rather than a migration. Nothing in the API now accepts a credential that stands for more than one caller: every request resolves to a specific user or a specific host, which is what lets a route say "the caller's own library" and mean it. BREAKING CHANGE: the `x-nestri-admin-token` header is no longer accepted and `ADMIN_SHARED_SECRET` is no longer read. `POST /games`, `GET /waitlist` and the `/pairing-code` routes are gone; `POST /games/sync` and `POST /library/sync` now require host credentials and take `userId` in the body; `POST /steam/link` no longer accepts `userId`; `POST /games/download-state` no longer accepts `hostId`.
118 lines
5.4 KiB
YAML
118 lines
5.4 KiB
YAML
# The whole control plane on one machine.
|
|
#
|
|
# Two uses, deliberately the same file. It is what a self-hoster runs, and it
|
|
# is the shape this deployment takes when it stops being a set of Workers: two
|
|
# stateless processes and a database, with a reverse proxy in front of them
|
|
# terminating TLS. Nothing here knows about a hosting provider.
|
|
#
|
|
# cp .env.example .env # then fill it in
|
|
# docker compose up --build everything, built from source
|
|
# docker compose up postgres just the database, for `bun dev`
|
|
#
|
|
# No service sets `container_name`. It reads like a nicety and behaves like a
|
|
# global: the name is not scoped to the project, so a second checkout of this
|
|
# repo — a worktree, a colleague's clone — gets the same three names, and
|
|
# `docker compose down` in one of them stops the containers belonging to the
|
|
# other. Compose names them per project on its own, which is what makes two
|
|
# checkouts independent.
|
|
#
|
|
# **There are no credentials in this file, and none of them have defaults.**
|
|
# Every one is read from `.env`, and compose refuses to start naming the
|
|
# variable it wanted rather than falling back to something. A default is worth
|
|
# less than it looks: the deployment that never set the variable is exactly the
|
|
# one where the default is a publicly known value.
|
|
#
|
|
# Migrations are not run for you — `bun run db:migrate` against DATABASE_URL,
|
|
# because a container that migrates on boot races with the second copy of
|
|
# itself and there is eventually a second copy.
|
|
|
|
x-postgres-url: &postgres-url
|
|
DATABASE_URL: postgres://${POSTGRES_USER:?set POSTGRES_USER in .env}:${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}@postgres:5432/${POSTGRES_DB:?set POSTGRES_DB in .env}
|
|
|
|
services:
|
|
postgres:
|
|
image: docker.io/postgres:18-alpine
|
|
environment:
|
|
POSTGRES_USER: ${POSTGRES_USER:?set POSTGRES_USER in .env}
|
|
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
|
|
POSTGRES_DB: ${POSTGRES_DB:?set POSTGRES_DB in .env}
|
|
# Loopback, not every interface. `5432:5432` would publish the database to
|
|
# anything that can reach this host. The three services below talk to each
|
|
# other over the compose network and do not use this mapping at all; it is
|
|
# here only so `bun dev` and `bun run db:migrate` can reach the database
|
|
# from outside a container.
|
|
ports:
|
|
- '127.0.0.1:5432:5432'
|
|
volumes:
|
|
- nestri_data:/var/lib/postgresql
|
|
healthcheck:
|
|
test: ['CMD-SHELL', 'pg_isready -U "$$POSTGRES_USER" -d "$$POSTGRES_DB"']
|
|
interval: 5s
|
|
timeout: 5s
|
|
retries: 10
|
|
|
|
auth:
|
|
build:
|
|
# The repository root, because the lockfile and the shared packages are
|
|
# there. Same reason for the API below.
|
|
context: .
|
|
dockerfile: apps/auth/Dockerfile
|
|
depends_on:
|
|
postgres:
|
|
condition: service_healthy
|
|
environment:
|
|
<<: *postgres-url
|
|
# Passed through rather than fixed here, so that setting them in `.env`
|
|
# is enough to make this deployment deliver mail. All three together or
|
|
# none of them: the issuer refuses to send when they are half configured.
|
|
EMAIL_SEND_URL: ${EMAIL_SEND_URL:-}
|
|
EMAIL_API_KEY: ${EMAIL_API_KEY:-}
|
|
EMAIL_FROM: ${EMAIL_FROM:-}
|
|
# Printing a live sign-in code to the log is a thing you ask for by name,
|
|
# and it is asked for in `.env` — not defaulted to here. With mail
|
|
# unconfigured and this unset, the issuer refuses to send rather than
|
|
# logging codes, which is the failure a self-hoster should get.
|
|
EMAIL_DEV_LOG: ${EMAIL_DEV_LOG:-}
|
|
# Every interface *inside the container*, which is what makes the
|
|
# loopback publication below reachable. The processes default to
|
|
# 127.0.0.1 because a bare process on a host has no such wrapper and a
|
|
# public bind there is a listener on the internet; a container's own
|
|
# loopback is not, and binding it would make the port unpublishable.
|
|
HOST: 0.0.0.0
|
|
# Loopback. This listener speaks plain HTTP and sets no `Secure` on the
|
|
# cookies it issues, because it expects to be behind something that
|
|
# terminates TLS. Published on every interface it would be a way to reach
|
|
# the issuer *around* that proxy, with codes and tokens in clear text.
|
|
ports:
|
|
- '127.0.0.1:1337:1337'
|
|
|
|
api:
|
|
build:
|
|
context: .
|
|
dockerfile: apps/api/Dockerfile
|
|
depends_on:
|
|
postgres:
|
|
condition: service_healthy
|
|
auth:
|
|
condition: service_started
|
|
environment:
|
|
<<: *postgres-url
|
|
# The issuer's public URL, and not `http://auth:1337`. A token carries
|
|
# the address it was minted through, and verification compares the two
|
|
# literally — so the name a browser used is the only one that can appear
|
|
# here. `AUTH_INTERNAL_URL` is how this container actually gets there.
|
|
AUTH_ISSUER_URL: ${AUTH_ISSUER_URL:?set AUTH_ISSUER_URL in .env}
|
|
AUTH_INTERNAL_URL: http://auth:1337
|
|
# Every interface *inside the container*, which is what makes the
|
|
# loopback publication below reachable. The processes default to
|
|
# 127.0.0.1 because a bare process on a host has no such wrapper and a
|
|
# public bind there is a listener on the internet; a container's own
|
|
# loopback is not, and binding it would make the port unpublishable.
|
|
HOST: 0.0.0.0
|
|
# Loopback, for the same reason as the issuer above.
|
|
ports:
|
|
- '127.0.0.1:3000:3000'
|
|
|
|
volumes:
|
|
nestri_data:
|