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
148 lines
5.2 KiB
JavaScript
148 lines
5.2 KiB
JavaScript
// ── SQL, and nothing else ─────────────────────────────────────────────────
|
|
//
|
|
// The `.db.js` half of the pair (see `servers.db.js` for why the split earns its
|
|
// keep). Raw parameterised SQL through `core.query`, placeholders always.
|
|
|
|
const core = require('../../core')
|
|
|
|
const LINKS = 'rust_account_links'
|
|
const PLAYERS = 'rust_players'
|
|
const STATS = 'rust_player_wipe_stats'
|
|
|
|
/**
|
|
* The link for one Steam id, or undefined.
|
|
*
|
|
* Joins core's `users` for the username, because every caller that asks "who
|
|
* owns this?" wants a name rather than an integer — and the one caller that
|
|
* refuses a re-link has to be able to say *whose* it is.
|
|
*/
|
|
async function getBySteamId(steamId) {
|
|
const rows = await core.query(
|
|
`SELECT l.steam_id AS steamId, l.user_id AS userId, l.name, l.server_id AS serverId,
|
|
l.linked_at AS linkedAt, u.username
|
|
FROM ${LINKS} l
|
|
JOIN users u ON u.id = l.user_id
|
|
WHERE l.steam_id = ?`,
|
|
[steamId],
|
|
)
|
|
return rows[0]
|
|
}
|
|
|
|
/** Every Steam account one website user holds, newest first. */
|
|
async function listForUser(userId) {
|
|
return core.query(
|
|
`SELECT steam_id AS steamId, user_id AS userId, name, server_id AS serverId,
|
|
linked_at AS linkedAt
|
|
FROM ${LINKS}
|
|
WHERE user_id = ?
|
|
ORDER BY linked_at DESC`,
|
|
[userId],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* Record a link.
|
|
*
|
|
* **A plain INSERT, never an upsert**, and that is the whole of D23 expressed in
|
|
* SQL. `ON DUPLICATE KEY UPDATE` here would silently move a Steam id from one
|
|
* website account to another — which, once phase 7 makes a link a privilege path
|
|
* and phase 13 makes it an entitlement, is an account takeover performed by
|
|
* typing a six-character code. The duplicate-key error is the refusal, and the
|
|
* controller turns it into a sentence.
|
|
*/
|
|
async function insert({ steamId, userId, name, serverId }) {
|
|
await core.query(
|
|
`INSERT INTO ${LINKS} (steam_id, user_id, name, server_id)
|
|
VALUES (?, ?, ?, ?)`,
|
|
[steamId, userId, name || null, serverId || null],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* Remove a link the caller owns.
|
|
*
|
|
* Scoped by `user_id` in the statement rather than checked before it: a delete
|
|
* that reads, decides, then writes has a gap between the read and the write, and
|
|
* this way the ownership test and the deletion are the same operation. Answers
|
|
* how many rows went, so a caller can tell "removed" from "was not yours".
|
|
*/
|
|
async function removeOwned(steamId, userId) {
|
|
const result = await core.query(
|
|
`DELETE FROM ${LINKS} WHERE steam_id = ? AND user_id = ?`,
|
|
[steamId, userId],
|
|
)
|
|
return Number(result && result.affectedRows) || 0
|
|
}
|
|
|
|
/**
|
|
* Remove a link whoever holds it — the in-game `/unlink` path, and the staff
|
|
* unlink on the `admin.users.detail` panel (D25).
|
|
*
|
|
* Unscoped by user on purpose: neither caller is the link's owner and both have
|
|
* already established their authority another way. In game the authority is the
|
|
* Steam account itself — whoever is connected as it is who it is; on the admin
|
|
* panel it is the tier gate. Which is why the admin caller writes an
|
|
* `activity.log` entry naming the operator and this does not: it cannot tell the
|
|
* two apart, and a log line that guessed would be worse than none.
|
|
*/
|
|
async function removeBySteamId(steamId) {
|
|
const result = await core.query(`DELETE FROM ${LINKS} WHERE steam_id = ?`, [steamId])
|
|
return Number(result && result.affectedRows) || 0
|
|
}
|
|
|
|
/**
|
|
* Every link one user holds, enriched with what this module knows about that
|
|
* player — for the `admin.users.detail` panel.
|
|
*
|
|
* A LEFT JOIN, because a player can link an account and never play on it. An
|
|
* operator looking at that user should see the link, not an empty panel.
|
|
*/
|
|
async function listForUserWithPlayer(userId) {
|
|
return core.query(
|
|
`SELECT l.steam_id AS steamId, l.name, l.server_id AS serverId, l.linked_at AS linkedAt,
|
|
p.name AS playerName, p.first_seen AS firstSeen, p.last_seen AS lastSeen
|
|
FROM ${LINKS} l
|
|
LEFT JOIN ${PLAYERS} p ON p.steam_id = l.steam_id
|
|
WHERE l.user_id = ?
|
|
ORDER BY l.linked_at DESC`,
|
|
[userId],
|
|
)
|
|
}
|
|
|
|
/**
|
|
* Per-server all-time totals for one Steam id.
|
|
*
|
|
* The same rows the public leaderboard sums, grouped by server instead of
|
|
* filtered to one — so an operator sees a player across the fleet in one read.
|
|
* All-time, deliberately: an admin looking at a user wants their history, not
|
|
* this week's.
|
|
*/
|
|
async function statsForSteamId(steamId) {
|
|
return core.query(
|
|
`SELECT s.server_id AS serverId, srv.name AS serverName,
|
|
SUM(s.kills) AS kills,
|
|
SUM(s.deaths) AS deaths,
|
|
SUM(s.npc_kills) AS npcKills,
|
|
SUM(s.structures) AS structures,
|
|
SUM(s.playtime_sec) AS playtimeSec,
|
|
MAX(s.last_seen) AS lastSeen,
|
|
COUNT(DISTINCT s.wipe_id) AS wipes
|
|
FROM ${STATS} s
|
|
LEFT JOIN rust_servers srv ON srv.id = s.server_id
|
|
WHERE s.steam_id = ?
|
|
GROUP BY s.server_id, srv.name
|
|
ORDER BY SUM(s.playtime_sec) DESC`,
|
|
[steamId],
|
|
)
|
|
}
|
|
|
|
module.exports = {
|
|
getBySteamId,
|
|
listForUser,
|
|
listForUserWithPlayer,
|
|
insert,
|
|
removeOwned,
|
|
removeBySteamId,
|
|
statsForSteamId,
|
|
}
|