wtclaude
b30e82cde2
The consumer half of a release module-uo's CI has been publishing since
phase 3 closed. Before this, core had the installed_modules provenance
columns and no code that could ever fill them: nothing fetched, verified,
unpacked, removed or purged anything, and there was no admin route at all.
Adds modules/archive.js, modules/install.js, schema.runPurge(),
lifecycle.stop(), loader.stopHook(), and /api/v1/admin/modules with eight
routes. 797 server tests (+76), manifest 158 -> 166 + 2 internal, OpenAPI
gains 8 operations and loses nothing.
Reject, never sanitise
----------------------
The download is the easy part: an https-only allowlist re-checked on every
redirect hop, a declared sha256 compared against the bytes that arrived, and
a byte cap. Unpacking is where the archive chooses the filenames, and core
writes into a directory bind-mounted from the host, so an escape is not
confined to the container.
archive.js inspects the whole archive before a byte is unpacked and refuses
absolute and drive-absolute paths, `..` segments, NUL bytes, backslashes,
anything that is not a regular file or a directory, more than one top-level
entry, and anything over the entry or byte caps. Refusing symlinks and
hardlinks outright is what keeps this off the majority of node-tar's
published advisories rather than depending on the library to contain them.
That two-pass shape is load-bearing, and it was measured rather than assumed:
extracting an archive whose fourth member escapes upward throws under
node-tar 7.5.22 -- and leaves the first three members on disk. The loader
scans that directory at require time on the next boot, so a half-unpacked
module is a module. Everything therefore happens in a scratch directory that
is removed on any failure, and the move into place is the last step.
`tar` is pinned to ^7.5.22 rather than the ^6 that installs by default: 6.x
is flagged critical, and reading the advisory list is what the file's header
now says out loud -- almost all of it is hardlink or symlink traversal and
PAX header interpretation differentials, which is exactly this feature's
threat model.
Two things the plan had wrong
-----------------------------
The bundle's top-level directory is `module-uo-<version>`, not the module id
-- so "the top-level name must equal the id" was checked against nothing real.
The extractor strips that level instead, because its name belongs to whoever
published the bundle and the directory it lands in is core's. What is checked
instead is the unpacked module.json: a manifest promising `uo` and delivering
something else is refused rather than installed under the name it promised.
And purge cannot be a follow-up action (decision 5): purge.sql lives inside
the directory uninstall deletes. It is offered in the uninstall flow and as a
standalone action on a still-installed module, and the standalone one refuses
unless the module is already disabled -- dropping tables under something that
is still serving leaves it answering out of a world that no longer exists.
Disable now means stopped
-------------------------
lifecycle.stop() dispatches that one module's onShutdown before flipping the
guard, so a module an operator switches off actually releases its sockets and
closes its streams instead of merely becoming unreachable. The hook runs
first and the state moves after it, because while onShutdown runs the module
is still `started` and that is the only state in which its routes and the
world it is tearing down agree. A hook that throws does not stop the disable
-- the opposite of the boot path's rule, and deliberately.
Enable is not its mirror and there is no start(id) beside it. There is no
onBoot re-dispatch and the hooks were never promised re-entrant, so enable
moves the row and the restart route starts it. A test pins that enable does
not touch the loader, because "fixing" it is a one-line change that would put
a module with closed sockets back on the nav.
Restart raises SIGTERM against its own process rather than calling the
shutdown path directly, so server.js's handler stays the one graceful-shutdown
path and this route cannot drift from it.
The allowlist bootstraps from MODULE_SOURCE_HOSTS into a settings row and is
admin-managed after that (decision 6); seedDefault is INSERT IGNORE, so
changing the variable on an existing deployment is a no-op by design. An empty
list forbids every install rather than allowing every host -- the safe
direction for a value someone might blank by accident.
Verified against the real v0.3.0 release
----------------------------------------
Not a fixture: fetched the published install manifest over the real Gitea
host and its redirect chain, verified the sha256, inspected and unpacked the
252,517-byte artifact to 82 files, and then booted core against the result --
the module registered its five mounts, seven streams and eight capabilities
and resolved its client chunk, with no scratch directory left behind.
Two defects this slice's own tooling caught, both of which had already been
written down as classes:
- the controller destructured runPurge at require time, capturing the
function rather than the module, which made the one dependency whose
ORDER matters the one that could not be substituted;
- two swagger annotations carried an apostrophe inside a quoted string,
dropped silently by swagger-autogen before slice 5 taught it to fail loudly.
Co-Authored-By: Claude <noreply@anthropic.com>
90 lines
4.5 KiB
JavaScript
90 lines
4.5 KiB
JavaScript
// /api/v1/admin — the admin surface, assembled from per-capability routers.
|
|
//
|
|
// This file owns exactly two things: the gate every admin route shares, and the
|
|
// mount table. No route is declared here. Each capability router mounts at the
|
|
// prefix it already owned inside the old monolithic admin.routes.js, so the
|
|
// emitted URL set is byte-identical — proved per PR by a zero-line diff in
|
|
// server/routes.manifest.json (`npm run routes:manifest`).
|
|
//
|
|
// The admin group is fully split as of PR 4: admin.routes.js is gone and every
|
|
// one of the 110 admin routes is declared in a capability router below.
|
|
//
|
|
// See docs/website/API_V2_PLAN.md § Phase 2 for the split.
|
|
|
|
const express = require('express')
|
|
|
|
const { isLoggedIn, requireRole } = require('../../../utils/auth')
|
|
const noindex = require('../../../middleware/noindex')
|
|
|
|
const accountRouter = require('./account.router')
|
|
const usersRouter = require('./users.router')
|
|
const invitesRouter = require('./invites.router')
|
|
const authProvidersRouter = require('./authProviders.router')
|
|
const moderationRouter = require('./moderation.router')
|
|
const botActivityRouter = require('./botActivity.router')
|
|
const activityRouter = require('./activity.router')
|
|
const postsRouter = require('./posts.router')
|
|
const uploadsRouter = require('./uploads.router')
|
|
const wikiRouter = require('./wiki.router')
|
|
const pagesRouter = require('./pages.router')
|
|
const emailRouter = require('./email.router')
|
|
const discordBotRouter = require('./discordBot.router')
|
|
const settingsRouter = require('./settings.router')
|
|
const modulesRouter = require('./modules.router')
|
|
const dashboardRouter = require('./dashboard.router')
|
|
|
|
const adminRouter = express.Router()
|
|
|
|
// Every admin route requires auth, a STAFF role, and is kept out of search
|
|
// indexes. The staff gate matters now that `player` is a logged-in-but-untrusted
|
|
// role: without it, the editor-tier routes below (dashboard, posts, wiki,
|
|
// uploads) that are only guarded by isLoggedIn would be reachable by players.
|
|
// Players get 403 here and use the self-scoped /player group instead.
|
|
//
|
|
// It lives here, ahead of every mount, so a capability router extracted in a
|
|
// later PR cannot silently ship without it.
|
|
const staffOnly = requireRole('admin', 'editor', 'moderator')
|
|
adminRouter.use(noindex, isLoggedIn, staffOnly)
|
|
|
|
adminRouter.use('/account', accountRouter)
|
|
adminRouter.use('/users', usersRouter)
|
|
adminRouter.use('/invites', invitesRouter)
|
|
// Mounted at /auth, not /auth/providers: /admin/auth is the capability, and the
|
|
// routes inside read as /providers[/:id].
|
|
adminRouter.use('/auth', authProvidersRouter)
|
|
// /moderation carries its own moderator gate; /bot-activity is admin-only per
|
|
// route. /activity is staff-wide — the audit log, not the bot-scoring state.
|
|
adminRouter.use('/moderation', moderationRouter)
|
|
adminRouter.use('/bot-activity', botActivityRouter)
|
|
adminRouter.use('/activity', activityRouter)
|
|
// Content, all editor-tier (no gate beyond staffOnly above). /uploads is the
|
|
// rich-text editors' generalized upload; /posts owns its own /posts/upload.
|
|
adminRouter.use('/posts', postsRouter)
|
|
adminRouter.use('/uploads', uploadsRouter)
|
|
adminRouter.use('/wiki', wikiRouter)
|
|
adminRouter.use('/pages', pagesRouter)
|
|
// Ops and configuration.
|
|
//
|
|
// `/shard` and `/uo-link` are absent here and are still served: they are
|
|
// module-uo's, mounted onto this same router by the loader after every core
|
|
// mount above (MODULE_API.md §2.4). The URLs did not move — the code did. That
|
|
// ordering is also what makes the prefixes unclaimable by anyone else: the
|
|
// loader asks this live router what core owns, so a second module claiming
|
|
// `/shard` is rejected against the mounts actually present, not against a list.
|
|
adminRouter.use('/email', emailRouter)
|
|
adminRouter.use('/discord-bot', discordBotRouter)
|
|
adminRouter.use('/settings', settingsRouter)
|
|
// The Modules screen (Phase 4). Core's, not a module's — and it has to be
|
|
// core's: it is how a module gets onto the volume in the first place. Mounted
|
|
// here alongside the other configuration capabilities, and admin-only per route
|
|
// rather than at this line, so the gate sits next to what it is guarding.
|
|
adminRouter.use('/modules', modulesRouter)
|
|
|
|
// The two singletons that own no path segment of their own: GET /dashboard and
|
|
// PUT /site-mode. Mounted at the group root, last, exactly where the residual
|
|
// admin.routes.js used to sit — safe because dashboard.router.js declares no
|
|
// router-level middleware, only its two routes.
|
|
adminRouter.use('/', dashboardRouter)
|
|
|
|
module.exports = adminRouter
|