mc-dashboard/app/api/players/route.ts

111 lines
3.1 KiB
TypeScript
Raw Normal View History

import { NextRequest, NextResponse } from "next/server";
import { readFileSync } from "fs";
Role-based access: admin vs superadmin - Credentials provider now resolves two distinct accounts from env: SUPERADMIN_USERNAME / SUPERADMIN_PASSWORD → role "superadmin" ADMIN_USERNAME / ADMIN_PASSWORD → role "admin" The role is carried through the JWT and Session callbacks so the UI and API can gate on it. Types extended via types/next-auth.d.ts. - lib/auth.ts exports requireRole(minRole) and sessionRole(session). - /api/players POST rejects "op" and "deop" with 403 unless the caller is superadmin. All other player actions (whitelist add/remove, ban, pardon) remain available to both roles. - lib/use-role.ts (client hook) exposes role / isSuperadmin / authed for UI gating without duplicating session typing. - PlayerManager: Add-OP button and per-row Deop action are hidden or disabled for non-superadmin; when a regular admin is viewing the Ops tab, a banner explains the read-only state. - PlayerDrawer: Make Op / Deop button disabled with tooltip for non-superadmin; whitelist, ban, pardon unchanged. - Navbar: subtle role pill next to the user name ("Super" for superadmin amber-tinted, "Admin" for admin). - Migration note: the existing ADMIN_* credentials now log in as the restricted admin role. Set SUPERADMIN_USERNAME + SUPERADMIN_PASSWORD in .env.local to retain operator-management ability. A placeholder superadmin account was generated in .env.local; the password is in the commit terminal output only, not the repo. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 06:52:05 -06:00
import { auth, sessionRole } from "@/lib/auth";
import { sendCommand } from "@/lib/rcon";
import { memo, invalidate } from "@/lib/cache";
export const dynamic = "force-dynamic";
const OPS_FILE = "/home/minecraft/server/ops.json";
const WHITELIST_FILE = "/home/minecraft/server/whitelist.json";
const BANNED_FILE = "/home/minecraft/server/banned-players.json";
type OpsEntry = { uuid: string; name: string; level: number };
type WhitelistEntry = { uuid: string; name: string };
type BannedEntry = { uuid: string; name: string; reason: string; created: string; expires: string };
function readJson<T>(path: string): T[] {
try {
return JSON.parse(readFileSync(path, "utf8"));
} catch {
return [];
}
}
// GET — list ops, whitelist, banned players
export async function GET() {
const session = await auth();
if (!session) {
return NextResponse.json({ error: "Unauthorized" }, { status: 403 });
}
const data = memo("players", 10_000, () => {
const ops = readJson<OpsEntry>(OPS_FILE).map((e) => ({
name: e.name,
uuid: e.uuid,
level: e.level,
}));
const whitelist = readJson<WhitelistEntry>(WHITELIST_FILE).map((e) => ({
name: e.name,
uuid: e.uuid,
}));
const banned = readJson<BannedEntry>(BANNED_FILE).map((e) => ({
name: e.name,
uuid: e.uuid,
reason: e.reason,
}));
return { ops, whitelist, banned };
});
return NextResponse.json(data, {
headers: { "Cache-Control": "private, max-age=5" },
});
}
// POST — execute a player management command
export async function POST(req: NextRequest) {
const session = await auth();
if (!session) {
return NextResponse.json({ error: "Unauthorized" }, { status: 403 });
}
const { action, player, reason } = await req.json();
if (!player || !/^[a-zA-Z0-9_]{1,16}$/.test(player)) {
return NextResponse.json(
{ error: "Invalid player name" },
{ status: 400 }
);
}
const allowedActions = ["op", "deop", "whitelist add", "whitelist remove", "ban", "pardon"];
if (!allowedActions.includes(action)) {
return NextResponse.json(
{ error: "Invalid action" },
{ status: 400 }
);
}
Role-based access: admin vs superadmin - Credentials provider now resolves two distinct accounts from env: SUPERADMIN_USERNAME / SUPERADMIN_PASSWORD → role "superadmin" ADMIN_USERNAME / ADMIN_PASSWORD → role "admin" The role is carried through the JWT and Session callbacks so the UI and API can gate on it. Types extended via types/next-auth.d.ts. - lib/auth.ts exports requireRole(minRole) and sessionRole(session). - /api/players POST rejects "op" and "deop" with 403 unless the caller is superadmin. All other player actions (whitelist add/remove, ban, pardon) remain available to both roles. - lib/use-role.ts (client hook) exposes role / isSuperadmin / authed for UI gating without duplicating session typing. - PlayerManager: Add-OP button and per-row Deop action are hidden or disabled for non-superadmin; when a regular admin is viewing the Ops tab, a banner explains the read-only state. - PlayerDrawer: Make Op / Deop button disabled with tooltip for non-superadmin; whitelist, ban, pardon unchanged. - Navbar: subtle role pill next to the user name ("Super" for superadmin amber-tinted, "Admin" for admin). - Migration note: the existing ADMIN_* credentials now log in as the restricted admin role. Set SUPERADMIN_USERNAME + SUPERADMIN_PASSWORD in .env.local to retain operator-management ability. A placeholder superadmin account was generated in .env.local; the password is in the commit terminal output only, not the repo. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 06:52:05 -06:00
if ((action === "op" || action === "deop") && sessionRole(session) !== "superadmin") {
return NextResponse.json(
{ error: "Only super admins can manage operators" },
{ status: 403 }
);
}
let command = `${action} ${player}`;
if (action === "ban" && reason) {
command += ` ${reason}`;
}
try {
const response = await sendCommand(command);
// Force server to sync JSON files
if (action.startsWith("whitelist")) {
await sendCommand("whitelist reload");
}
// Wait for server to write JSON files to disk
await new Promise((r) => setTimeout(r, 500));
invalidate("players");
return NextResponse.json({ ok: true, response });
} catch (e) {
return NextResponse.json(
{ error: `RCON failed: ${(e as Error).message}. Is the server online?` },
{ status: 500 }
);
}
}