wtclaude
8fd0d82580
PR 4 of the in-place admin router split (docs/website/API_V2_PLAN.md § Phase 2),
and the last admin one: it moves the entire residual 33 and DELETES
admin.routes.js. Every one of the 110 admin routes is now declared in a
capability router. No URL, gate or handler changes.
shard.router.js (16) /admin/shard
uoLink.router.js ( 5) /admin/uo-link
email.router.js ( 6) /admin/email
discordBot.router.js ( 2) /admin/discord-bot
settings.router.js ( 2) /admin/settings
dashboard.router.js ( 2) GET /dashboard + PUT /site-mode, at the group root
admin.routes.js deleted, was 33
No gate moved to router level. Every adminOnly in the residual file was
per-route, and modAccess on /shard must stay per-route because half that router
must not have it — which keeps the per-route handler count intact, the one
number routes.guards.json can actually check.
/shard is the first prefix where two tiers share one router: 7 self-service
account-linking routes (no extra gate, served by the same player/shard
controller handlers, tagged `Admin · Account`) alongside 9 in-game staff ops on
modAccess. Prefix ownership beats tag grouping — splitting by tag would put two
routers under one prefix for no gain. The tag mismatch stays; retagging is a
real spec diff and belongs in a PR about tags.
dashboard.router.js is the one router mounted at the group root rather than a
prefix: GET /dashboard and PUT /site-mode share no path segment. That is safe
only because the file declares no router-level middleware — a bare use(gate) in
a root-mounted router would run for every request passing through toward
another mount. The file carries a comment saying so.
Acceptance — all four gates zero-diff:
routes.manifest.json unchanged (200 public + 2 internal)
routes.guards.json unchanged (no route lost or gained a gate)
swagger-output.json unchanged (198 operations)
api-route-inventory.json already in sync
plus 434 server tests green.
Verified separately, because no gate can catch it: introspecting the built
stack, all 59 literal admin paths still dispatch to their own layer — nothing
is captured first by a /:param sibling. The manifest sorts its entries, so
declaration order is invisible to it.
Also repoints the comments that referenced admin.routes.js by name
(botActivity/moderation controllers, the town-crier cap mirror in
announceJobs.logic.js) and generalizes the "the path is on the line after
router.get(" rationale in routeManifest.js, README.md and pr-checks.yml, which
was never about that one file.
Co-Authored-By: Claude <noreply@anthropic.com>
32 lines
1.4 KiB
JavaScript
32 lines
1.4 KiB
JavaScript
// Bot-scoring / IP-ban visibility for admins. Read-only view of the botScore
|
|
// middleware's in-memory state plus a recent-events feed, and a single mutating
|
|
// action — an emergency unban for false positives. Mounted behind the admin-only
|
|
// RBAC gate (see botActivity.router.js). This is visibility + emergency unban only;
|
|
// there is deliberately no way to add a ban or change scoring weights from here.
|
|
|
|
const botScore = require('../../../middleware/botScore')
|
|
const activity = require('../../../model/activity/activity.model')
|
|
|
|
const log = require('../../../utils/logger')('botactivity')
|
|
|
|
// Current store state (all scored IPs, banned or not) plus the recent-events
|
|
// buffer, most-recent-first. Both are in-memory and reset on process restart.
|
|
async function getBotActivity(req, res) {
|
|
return res.json({
|
|
ips: botScore.listState(),
|
|
events: botScore.recentEvents(),
|
|
})
|
|
}
|
|
|
|
// Emergency unban: clear a single IP's entry so it is no longer banned or
|
|
// carrying score. A real administrative action — logged with the admin user.
|
|
async function unbanIp(req, res) {
|
|
const ip = req.body.ip
|
|
const removed = botScore.unban(ip)
|
|
await activity.log({ req, action: 'botscore.unban', detail: { ip, removed } })
|
|
log.info('IP unbanned by admin', { ip, admin: req.user.username, removed })
|
|
return res.json({ ip, removed })
|
|
}
|
|
|
|
module.exports = { getBotActivity, unbanIp }
|