R1's identity link, site-side, and R13's first extension slot. A player types /link in game, the plugin hands them a six-character code privately, and they enter it here; the site records who owns which Steam account, and an operator sees that on core's own `/admin/users/:id` page. **The site is the author of record and the game holds nothing.** There is no per-account store in Rust that survives a wipe, and phase 7 needs the site authoritative anyway — it pushes permissions INTO the game keyed by Steam id. A copy in the game would be a second thing to reconcile every wipe, for no question it could answer better. ## D24 — a code is minted by ONE server, so every server is asked Nothing in six characters says where it came from. The fleet is asked in turn and the first `link.ok` wins; the others answer `unknown` and nothing happens there, because a code is only spent at the server that actually holds it. Asking the player to pick was rejected: a wrong pick would come back indistinguishable from a wrong code, and that is the one refusal which must not be ambiguous. **"Every reachable server refused" is not the same answer as "a server was unreachable."** Collapsing them tells a player whose server is down that their code is wrong — so they run /link again on that same server and are told the same thing for as long as it stays down. `unsure` is that case, and it says to try again rather than to fetch a new code. ## D23 — a Steam id another account holds is refused, never moved The primary key is `steam_id`, and it is load-bearing rather than tidy: phase 7 grants permissions against a link and phase 13 hangs entitlements off it, so a silent move is an account takeover performed by typing six characters. The refusal names the holder, because the advice is unusable without it. The INSERT is a plain INSERT for the same reason — `ON DUPLICATE KEY UPDATE` here would BE that move — and the duplicate-key error is the refusal for the race the check above cannot close. The way out is `/unlink` in game, which reaches the site off the ingest feed rather than through a route (the plugin has no link to delete). D25 adds the other way out: staff can sever a link from the admin panel, for a player who cannot reach that Steam account in game. ## The slot, and the hole it found in this repo's own generator `admin.users.detail` is declared in `module.json` AND registered in `index.js` AND filled by the chunk — three places, because the server half and the client half are different registrations that share one name. `swaggerFragment.js` knew only about tier routers, so the two routes under `/admin/users/:id` were generated by nothing: a fragment that was internally consistent and described two routes fewer than the module serves. A slot's mount is core's and cannot be derived here, so it is a fourth constant beside `TIER_BASE` — held to account by the frozen-manifest job, which was verified to catch exactly this by removing the two paths and watching it fail. ## Smaller things worth knowing - **Core's `useAsync` has no `refresh`.** A counter in the deps is how a page re-reads after its own write; it blanks while it re-reads, which is right here and is exactly what made it wrong for a poll. - **Every player-portal nav row needs an `icon`** — core draws one on every row, and the client suite says so. This module had no icons file until now, because the public header is text buttons. - The two new frame kinds are STAFF-only. Neither carries a code, but both name a Steam id beside a website account's activity, and that join is not a public fact about what happened on a server. - The link code route carries its own rate limiter rather than core's `accountChangeLimiter`: this is guessing somebody else's secret, not changing your own password, and a shared counter would let one policy set the other. Protocol 3 on all three declaration sites; 17 new tests, 136 green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM
122 lines
6.4 KiB
JavaScript
122 lines
6.4 KiB
JavaScript
// ── The server entry point ─────────────────────────────────────────────────
|
|
//
|
|
// Core requires this file once, synchronously, while its own `app.js` is still
|
|
// being required, and calls the exported function with `(ctx, api)`. That is the
|
|
// entire server-side handshake: everything this module can reach arrives on
|
|
// `ctx`, and everything it can offer is registered through `api`.
|
|
//
|
|
// Normative: MODULE_API.md §2.2 (the entry point) and §2.4 (what you register).
|
|
//
|
|
// ── Three rules, and each one has a failure behind it ──────────────────────
|
|
//
|
|
// 1. **No `await`, and no database.** Core requires `app.js` in two build tools
|
|
// with the connection pool pointed at a dead port — the route-manifest
|
|
// generator and the OpenAPI generator both do it — so a module that queried
|
|
// at registration time would hang both. Anything that needs a live database
|
|
// goes in `onBoot`, which runs after the schema is up.
|
|
//
|
|
// 2. **Never resolve what core owns.** This module lives at
|
|
// `<website>/modules/rust/`, outside core's `server/`, so Node's resolver
|
|
// never reaches core's `node_modules` and `require('express')` from here
|
|
// simply fails. express, express-validator, the database, the logger and the
|
|
// middleware all arrive on `ctx` (§2.3) and are re-exported by `./core`. A
|
|
// second express in the process would be a second `Router` prototype, exactly
|
|
// as a second React would be a second renderer.
|
|
//
|
|
// 3. **Never reach into core's tree.** No relative path may escape this module's
|
|
// root. `scripts/checkImports.js` enforces it (§5.1) and CI runs it.
|
|
//
|
|
// ── Why the requires are INSIDE the function ───────────────────────────────
|
|
//
|
|
// Every file below reaches core through `./core`, whose members resolve `ctx`
|
|
// when they are CALLED. But a router writes `const express = core.express` at its
|
|
// own file scope, and that runs the moment the file is required. So
|
|
// `core.init(ctx)` has to happen before the first `require` of anything under
|
|
// `router/`. Hoisting these to the top of the file breaks the module with an
|
|
// error about a missing `ctx`, thrown from a file that never mentions one.
|
|
//
|
|
// Node caches modules, so requiring here costs nothing after the first call.
|
|
|
|
const core = require('./core')
|
|
|
|
/**
|
|
* @param {object} ctx what core hands the module (MODULE_API.md §2.3), frozen
|
|
* @param {object} api what the module registers (§2.4)
|
|
*/
|
|
module.exports = function register(ctx, api) {
|
|
core.init(ctx)
|
|
|
|
/* eslint-disable global-require */
|
|
const publicRust = require('./router/public/rust.router')
|
|
const playerRust = require('./router/player/rust.router')
|
|
const adminRust = require('./router/admin/rust.router')
|
|
const usersRust = require('./router/admin/usersRust.router')
|
|
const boot = require('./boot')
|
|
/* eslint-enable global-require */
|
|
|
|
const log = core.logger()
|
|
|
|
// One prefix, on each of the three tiers (R14). The keys here must match
|
|
// `module.json`'s `mounts` exactly — the loader compares the two and rejects a
|
|
// mismatch in EITHER direction, so a route never declared and a prefix declared
|
|
// and never registered both fail loudly at boot rather than quietly at runtime.
|
|
//
|
|
// Each router sits INSIDE its tier router, so it structurally cannot reach
|
|
// above its prefix, and the tier's gate is already applied: `public` is behind
|
|
// nothing by design, `admin` behind `noindex, isLoggedIn, requireRole(...)` and
|
|
// `player` behind `noindex, requireAuth`. Per-route gates go on top; the tier
|
|
// gate is never re-implemented.
|
|
//
|
|
// **Prefixes share ONE namespace with core's own, and the collision probe
|
|
// cannot see all of it.** Core answers several public routes mounted at the
|
|
// tier root rather than under a prefix — `/status` and `/version` among them —
|
|
// and the loader's check cannot find those. `/rust` collides with nothing on
|
|
// any of the three tiers, checked against core's mount tables rather than
|
|
// assumed.
|
|
api.registerRoutes({
|
|
public: { '/rust': publicRust },
|
|
player: { '/rust': playerRust },
|
|
admin: { '/rust': adminRust },
|
|
})
|
|
|
|
// R13's first extension slot (§2.4). Core declares `admin.users.detail` on
|
|
// `/api/v1/admin/users/:id` and we fill it; the router receives the parent's
|
|
// `req.params.id` through `mergeParams`. Core's own routes on the resource are
|
|
// declared before the slot is mounted, so core wins any path conflict — it owns
|
|
// the user, and this module owns what it can say about one.
|
|
//
|
|
// **It is declared twice, in two different places, on purpose.** This call is
|
|
// the SERVER half and `module.json`'s `extensions` array is held against it by
|
|
// the loader. The CLIENT half is `registry.registerExtension(ID,
|
|
// 'admin.users.detail', …)` in `entry.jsx` and must NOT appear in that array —
|
|
// phase 1 found that the hard way with `site.footer.status`, which is a client
|
|
// slot and fails the load outright when named there.
|
|
api.registerExtension('admin.users.detail', usersRust)
|
|
|
|
// The lifecycle hooks (§2.5). `onBoot` runs after core's schema, after this
|
|
// module's schema fragment, and BEFORE the HTTP listener binds — so a module
|
|
// that must not serve traffic until it has warmed a cache gets that for free.
|
|
// It has no timeout, deliberately: a slow boot delays the listener, which is the
|
|
// guarantee rather than a problem to be timed out.
|
|
//
|
|
// `onShutdown` runs while core's database pool and push dispatcher are still
|
|
// open, because flushing through them is the only thing it is for. It gets a
|
|
// five-second budget and is abandoned past it.
|
|
api.onBoot(boot.onBoot)
|
|
api.onShutdown(boot.onShutdown)
|
|
|
|
// Everything else this module will register — the Team provider, the event
|
|
// triggers and audiences, the engagement seeds, the four event catalogues, the
|
|
// notification streams and the slash commands — is deliberately absent. Each
|
|
// arrives with the phase that has something real to put in it. A registration
|
|
// with nothing behind it is worse than a missing one: a declared trigger
|
|
// nothing emits and a declared slot nothing fills are both surfaces an operator
|
|
// can configure and then wait on.
|
|
|
|
log.info('registered', {
|
|
version: require('../module.json').version,
|
|
routes: 'public:/rust player:/rust admin:/rust',
|
|
extensions: 'admin.users.detail',
|
|
})
|
|
}
|