Author SHA1 Message Date
D4rkst3randClaude Opus 5 00e4774a5f feat(whitelist): /whitelist add und remove
Deploy / check (push) Canceled after 0s
Deploy / deploy (push) Canceled after 0s
Der lesende Weg ist am 04.09.2026 mit echten Daten durchgelaufen
("ja (2 von 2 Zutrittsrollen)"), also kommt jetzt die schreibende
Haelfte - in dieser Reihenfolge und nicht umgekehrt.

Welche Rolle vergeben wird
--------------------------
d4rk_discord:grantrole, eine EIGENE Convar in secrets.cfg. Nicht das
Adminpanel: eine Rollen-ID, die man an einer zweiten Stelle pflegt,
laeuft von der ersten weg - genau daran ist heute frueh schon das
Eingabefeld gescheitert. Die Rollenpolitik liegt vollstaendig in
secrets.cfg.

SIE MUSS EINE DER ZUTRITTSROLLEN SEIN. d4rk_lib prueft das und meldet
`vergabeGueltig`; ist sie es nicht, verweigert der Befehl. Eine Rolle
zu vergeben, die niemanden hereinlaesst, waere ein Knopf, der nichts
tut und dabei "erledigt" meldet - und das faellt erst auf, wenn jemand
vor der Tuer steht.

NICHT GESETZT IST KEIN FEHLER, sondern der Zustand im geschlossenen
Test. Der Befehl sagt das dann auch so.

Was geprueft wird, bevor etwas passiert
---------------------------------------
Rechtesystem erreichbar - Aufrufer hat d4rk.whitelist - Rollen lesbar -
Vergaberolle gesetzt - Vergaberolle oeffnet Zutritt - Person ist auf
dem Discord - Rolle existiert - Bot hat "Rollen verwalten" - Rolle
steht unter der hoechsten Rolle des Bots.

Die Hierarchiepruefung ist keine Kosmetik: ohne sie kommt eine nackte
HTTP-50013, und die liest sich wie "der Bot ist kaputt" statt wie "die
Rolle steht zu weit oben".

"Hat sie schon" und "hat sie gar nicht" sind Antworten, keine
Fehlschlaege.

Wo es landet
------------
Im Devlog-Kanal (neuer Helfer melden.js:inDevlog, wirft nie - ein
fehlgeschlagener Logeintrag darf den Vorgang nicht mitreissen, ueber
den er berichtet). NICHT im Serverprotokoll: der Weg dorthin ginge nur
ueber einen Schreibzugang fuer den Bot, und der wuerde die absichtlich
schmale Tuer aufmachen. Die Freischaltung steht ausserdem in Discords
Audit-Log, und beim Verbinden protokolliert d4rk_lib die Zulassung mit
Namen.

Gemessen
--------
Befehlsdefinition gebaut: whitelist status(person*) add(person*,grund)
remove(person*,grund), keine Ueberschreitung der Discord-Grenzen. Die
Grenzpruefung hat eine Kontrolle mit bekanntem Ausgang, die anschlaegt -
sonst waere "nichts ueber der Grenze" von "Pruefung ist blind" nicht zu
unterscheiden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 12:23:23 +02:00
D4rkst3randClaude Opus 5 90fefb2865 feat(zutritt): die Rollen werden gelesen, nicht abgeschrieben
Deploy / check (push) Canceled after 0s
Deploy / deploy (push) Canceled after 0s
GEMESSEN am 04.09.2026 an der Serverkonsole:

    "d4rk_discord:role" is "1439019849664696460,1544029550802108437"

ZWEI Rollen. Im Adminpanel stand seit heute frueh ein Eingabefeld, in
dem EINE davon stand. Wer nur die andere hat, kommt auf den Server -
und /whitelist status haette ihm "Whitelist-Rolle: nein" gesagt.

Das ist die Sorte Fehler, vor der der Kommentar an genau dieser Stelle
gewarnt hat, waehrend der Code daneben sie gebaut hat: zwei Orte fuer
dieselbe Wahrheit.

Was sich aendert
----------------
d4rk_lib exportiert `ZutrittRollen` - DIESELBE Parsung, die auch die
Zutrittspruefung benutzt, nicht eine zweite. Sie gibt Zutrittsrollen,
Sperrrollen, den ACE-Notausgang und ob der Discord-Token gesetzt ist
(nur ob, nie den Wert).

d4rk_web reicht das als /zutritt heraus. Nur lesend: setzen kann das
Panel es nicht, die Convar steht in secrets.cfg und wirkt erst nach
einem Serverstart. Ein Feld, das sich speichern laesst und nichts
aendert, ist schlimmer als keines.

Das Panel zeigt es an, statt es abzufragen. Das Eingabefeld ist weg;
ein bereits gespeicherter Wert bleibt unbeachtet liegen, statt beim
Start still geloescht zu werden.

Der Bot prueft gegen die MENGE, nicht gegen eine ID, und nennt die
Zahl ("ja (1 von 2)"). Die Sperrrolle wird ZUERST geprueft - sie
schlaegt jede Zutrittsrolle, und sie danach zu pruefen liesse ein "ja"
stehen fuer jemanden, der nicht hereinkommt.

KEIN RUECKFALL AUF EINE GESPEICHERTE ID mehr. Eine veraltete Liste
antwortet selbstbewusst falsch; "nicht pruefbar" ist die richtige
Antwort auf eine Frage, die man gerade nicht beantworten kann.

Gemessen nach dem Neustart:
  /zutritt -> rollen: 2, sperrrollen: 0, aceKnoten d4rk.whitelist,
              tokenGesetzt true  - deckt sich mit der Konsole

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 12:11:27 +02:00
D4rkst3randClaude Opus 5 8b4efb2cb9 feat(bot): Whitelist-Rolle kommt vom Panel, nicht aus der Umgebung
Deploy / check (push) Canceled after 0s
Deploy / deploy (push) Canceled after 0s
Zwei Aenderungen, die zusammengehoeren.

1. darfWhitelist las ein Feld, das es nicht mehr gibt
------------------------------------------------------
/person im Spielserver nimmt jetzt das zu pruefende Recht als Parameter
und antwortet mit `darf` statt mit `darfWhitelist`. Der alte Zugriff
haette ab sofort still immer false ergeben - also: jeder im Team
ausgesperrt, ohne eine Fehlermeldung, die darauf hindeutet.

`person()` nimmt das Recht jetzt optional mit; ohne Recht bleibt der
Aufruf, was er war.

2. Die Rollen-ID stand an zwei Orten
------------------------------------
Sie muss zu der passen, die der Spielserver prueft. Stimmen sie nicht
ueberein, zeigt /whitelist status "hat die Rolle" fuer eine Rolle, die
den Zutritt gar nicht oeffnet - ein Fehler, der wie eine richtige
Antwort aussieht.

Deshalb wird sie nur noch an EINEM Ort eingetragen: auf der
Einstellungsseite des Adminpanels. Der Bot holt sie ueber /bot/config,
30 Sekunden gepuffert. Ein Fehlschlag wird NICHT gepuffert, sonst bliebe
eine Stoerung eine halbe Minute stehen, nachdem sie vorbei ist.

WHITELIST_ROLE_ID bleibt als Rueckfall, damit der Befehl auch dann noch
etwas anzeigen kann, wenn das Panel nicht antwortet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 10:58:47 +02:00
4 changed files with 294 additions and 25 deletions
+6 -2
View File
@@ -49,8 +49,12 @@ services:
# eingerichtet" sagt.
ACP_URL: ${ACP_URL:-}
ACP_BOT_TOKEN: ${ACP_BOT_TOKEN:-}
# Die Discord-Rolle, die den Zutritt oeffnet. Muss dieselbe sein, die der
# Spielserver prueft (Convar d4rk_discord:role).
# Die Discord-Rolle, die den Zutritt oeffnet. NUR NOCH RUECKFALL: seit
# dem 04.09.2026 holt der Bot sie vom Adminpanel (/bot/config), wo sie
# auf der Seite "Einstellungen" eingetragen wird. Was dort steht, gewinnt.
#
# Der Rueckfall bleibt, damit /whitelist auch dann noch etwas anzeigen
# kann, wenn das Panel gerade nicht antwortet.
WHITELIST_ROLE_ID: ${WHITELIST_ROLE_ID:-}
# HTTP-Endpoint für Gitea-Webhooks + Webinterface
# NPM leitet bot.d4rkst3r.de → host.docker.internal:3080
+214 -19
View File
@@ -14,23 +14,62 @@
// Matrix.
//
// ============================================================================
// DIESER BEFEHL LIEST NUR
// DREI UNTERBEFEHLE, EINE RECHTEPRUEFUNG
// ============================================================================
// `status` beantwortet drei Fragen an einem Ort: hat die Person die Rolle,
// kennt der Spielserver ihr Konto, und welche Teamrolle hat sie bei uns.
// `status` liest, `add` und `remove` schreiben. Alle drei fragen zuerst den
// Spielserver, ob der Aufrufer `d4rk.whitelist` hat.
//
// Das Vergeben und Entziehen kommt als eigener Schritt — erst wenn dieser
// Weg nachweislich durchläuft. Ein Schreibbefehl auf einem Kanal, den niemand
// gemessen hat, ist ein Schreibbefehl ins Ungewisse.
// Das Schreiben kam bewusst SPAETER als das Lesen: erst am 04.09.2026, nachdem
// der lesende Weg mit echten Daten durchgelaufen war („ja (2 von 2
// Zutrittsrollen)"). Ein Schreibbefehl auf einem Kanal, den niemand gemessen
// hat, ist ein Schreibbefehl ins Ungewisse.
//
// ============================================================================
// WAS DER BOT VERGIBT, ENTSCHEIDET DER SPIELSERVER
// ============================================================================
// Die Rolle steht in `d4rk_discord:grantrole` und MUSS eine der Rollen sein,
// die auch Zutritt oeffnen. Ist sie es nicht, verweigert dieser Befehl — eine
// Rolle zu vergeben, die niemanden hereinlaesst, waere ein Knopf, der nichts
// tut und dabei „erledigt" meldet.
//
// ============================================================================
// WO DAS LANDET
// ============================================================================
// Im Devlog-Kanal des Bots, nicht im Serverprotokoll. Der Weg dorthin ginge
// nur ueber einen Schreibzugang fuer den Bot, und der wuerde die absichtlich
// schmale Tuer aufmachen (siehe panel.js). Die Freischaltung selbst steht
// ausserdem in Discords eigenem Audit-Log, und wenn die Person verbindet,
// protokolliert d4rk_lib die Zulassung mit Namen.
import { SlashCommandBuilder, MessageFlags } from 'discord.js';
import { person, panelBereit, darfWhitelist } from '../../panel.js';
import { person, panelBereit, darfWhitelist, konfig } from '../../panel.js';
import { inDevlog } from '../../melden.js';
// Die Rollen-ID kommt aus derselben Umgebung wie der Rest der Botkonfiguration.
// Sie ist kein Geheimnis, aber sie muss zu der passen, die der Spielserver
// prüft (`d4rk_discord:role`) — stimmen sie nicht überein, zeigt dieser Befehl
// „hat die Rolle" für eine Rolle, die den Zutritt gar nicht öffnet.
const WHITELIST_ROLLE = process.env.WHITELIST_ROLE_ID || '';
/*
DIE ROLLEN WERDEN GELESEN, NICHT GEPFLEGT.
Sie sind kein Geheimnis, aber sie müssen zu denen passen, die der
Spielserver prüft (`d4rk_discord:role`) — sonst zeigt dieser Befehl „hat die
Rolle" für eine Rolle, die den Zutritt gar nicht öffnet.
Am 04.09.2026 gemessen: die Convar enthielt ZWEI Rollen, eingetragen war
eine. Deshalb kommt die Menge jetzt vom Spielserver.
ES SIND MEHRERE, UND EINE REICHT. Wer eine davon hat, kommt herein — außer
er hat eine Sperrrolle, die schlägt alles. Das ist dieselbe Regel wie in
d4rk_lib; sie hier zu vereinfachen hieße, sie ein zweites Mal zu schreiben.
KEIN RÜCKFALL AUF EINE GESPEICHERTE ID. Eine veraltete Liste würde
selbstbewusst falsch antworten; „nicht prüfbar" ist die richtige Antwort auf
eine Frage, die man gerade nicht beantworten kann.
*/
async function zutritt() {
const k = await konfig();
if (!k.ok || k.zutrittGelesen !== true || !k.zutritt) return null;
return k.zutritt;
}
const GRUENDE = {
nicht_eingerichtet:
@@ -51,6 +90,26 @@ export const data = new SlashCommandBuilder()
.addUserOption((o) =>
o.setName('person').setDescription('Wen nachschlagen?').setRequired(true)
)
)
.addSubcommand((s) =>
s.setName('add')
.setDescription('Jemanden freischalten')
.addUserOption((o) =>
o.setName('person').setDescription('Wen freischalten?').setRequired(true)
)
.addStringOption((o) =>
o.setName('grund').setDescription('Warum? Steht später im Log.').setRequired(false)
)
)
.addSubcommand((s) =>
s.setName('remove')
.setDescription('Freischaltung zurücknehmen')
.addUserOption((o) =>
o.setName('person').setDescription('Wem?').setRequired(true)
)
.addStringOption((o) =>
o.setName('grund').setDescription('Warum? Steht später im Log.').setRequired(false)
)
);
export async function execute(interaction) {
@@ -86,6 +145,12 @@ export async function execute(interaction) {
}
const ziel = interaction.options.getUser('person', true);
const was = interaction.options.getSubcommand();
if (was === 'add' || was === 'remove') {
return schreiben(interaction, ziel, was, erlaubnis.rolle);
}
const p = await person(ziel.id);
if (!p.ok) {
@@ -99,18 +164,31 @@ export async function execute(interaction) {
Verbindung. Wer sie hier vom Server erwartet, bekommt eine Antwort, die
geraten wäre.
*/
let rolleText = 'nicht prüfbar — `WHITELIST_ROLE_ID` ist nicht gesetzt';
const z = await zutritt();
if (WHITELIST_ROLLE) {
let rolleText = 'nicht prüfbar — der Spielserver sagt gerade nicht, welche Rollen gelten';
if (z && z.rollen.length === 0) {
rolleText = 'keine Zutrittsrolle konfiguriert — die Whitelist ist offen';
} else if (z) {
const mitglied = await interaction.guild?.members
.fetch(ziel.id)
.catch(() => null);
rolleText = !mitglied
? 'nicht auf diesem Discord'
: mitglied.roles.cache.has(WHITELIST_ROLLE)
? '**ja**'
: '**nein**';
if (!mitglied) {
rolleText = 'nicht auf diesem Discord';
} else {
const hat = z.rollen.filter((r) => mitglied.roles.cache.has(r));
const gesperrt = (z.sperrrollen ?? []).some((r) => mitglied.roles.cache.has(r));
// DIE SPERRE ZUERST: sie schlägt die Zutrittsrolle. Sie danach zu
// nennen ließe „ja" stehen für jemanden, der nicht hereinkommt.
rolleText = gesperrt
? '**gesperrt** — eine Sperrrolle schlägt jede Zutrittsrolle'
: hat.length > 0
? `**ja** (${hat.length} von ${z.rollen.length} Zutrittsrollen)`
: `**nein** (keine von ${z.rollen.length})`;
}
}
const k = p.konto;
@@ -141,3 +219,120 @@ export async function execute(interaction) {
return interaction.editReply(zeilen.filter(Boolean).join('\n'));
}
/**
* Freischalten oder zurücknehmen.
*
* SIEBEN PRÜFUNGEN, BEVOR ETWAS PASSIERT. Jede davon hat einen eigenen Satz —
* „geht nicht" ist keine Auskunft, mit der jemand weiterkommt.
*/
async function schreiben(interaction, ziel, was, aufruferRolle) {
const z = await zutritt();
if (!z) {
return interaction.editReply(
'Der Spielserver sagt gerade nicht, welche Rollen gelten — ich schalte nichts frei, was ich nicht prüfen kann.'
);
}
if (!z.vergaberolle) {
return interaction.editReply(
'Es ist keine Rolle zum Vergeben eingetragen (`d4rk_discord:grantrole` in `secrets.cfg`). Bis dahin kann ich niemanden freischalten.'
);
}
/*
DIE ROLLE MUSS AUCH ZUTRITT OEFFNEN.
Sonst vergibt der Befehl etwas Wirkungsloses und meldet Erfolg — die
unangenehmste Sorte Fehler, weil sie erst auffaellt, wenn jemand vor der
Tuer steht.
*/
if (!z.vergabeGueltig) {
return interaction.editReply(
`Die eingetragene Vergaberolle (\`${z.vergaberolle}\`) ist **keine** der Rollen, die Zutritt öffnen. ` +
'Ich vergebe sie nicht — sie würde niemanden hereinlassen.'
);
}
const mitglied = await interaction.guild?.members.fetch(ziel.id).catch(() => null);
if (!mitglied) {
return interaction.editReply(`${ziel.tag} ist nicht auf diesem Discord.`);
}
/*
KANN ICH DIE ROLLE UEBERHAUPT VERGEBEN?
Discord laesst einen Bot nur Rollen UNTERHALB seiner eigenen hoechsten
vergeben. Ohne diese Pruefung kommt eine nackte HTTP-50013, und die liest
sich wie „der Bot ist kaputt" statt wie „die Rolle steht zu weit oben".
*/
const rolle = interaction.guild.roles.cache.get(z.vergaberolle)
?? await interaction.guild.roles.fetch(z.vergaberolle).catch(() => null);
if (!rolle) {
return interaction.editReply(
`Die Rolle \`${z.vergaberolle}\` gibt es auf diesem Discord nicht. Steht in \`secrets.cfg\` die richtige ID?`
);
}
const ich = interaction.guild.members.me;
if (!ich?.permissions.has('ManageRoles')) {
return interaction.editReply('Mir fehlt das Recht **Rollen verwalten** auf diesem Discord.');
}
if (rolle.position >= ich.roles.highest.position) {
return interaction.editReply(
`**${rolle.name}** steht in der Rollenliste über meiner höchsten Rolle — Discord lässt mich sie deshalb nicht vergeben. ` +
'Schieb meine Rolle darüber.'
);
}
const hatte = mitglied.roles.cache.has(rolle.id);
// NICHTS ZU TUN IST EINE ANTWORT, KEIN FEHLSCHLAG.
if (was === 'add' && hatte) {
return interaction.editReply(`${ziel.tag} hat **${rolle.name}** bereits.`);
}
if (was === 'remove' && !hatte) {
return interaction.editReply(`${ziel.tag} hat **${rolle.name}** gar nicht.`);
}
const grund = interaction.options.getString('grund') || null;
const spur = `${interaction.user.tag} (${aufruferRolle})${grund ? `${grund}` : ''}`;
try {
if (was === 'add') await mitglied.roles.add(rolle, spur);
else await mitglied.roles.remove(rolle, spur);
} catch (fehler) {
return interaction.editReply(
`Discord hat es abgelehnt: ${fehler?.message ?? 'unbekannt'}`
);
}
/*
ERST HANDELN, DANN MELDEN - und die Meldung darf nicht mitreissen.
Ein fehlgeschlagener Logeintrag waere ein schlechter Grund, eine bereits
vergebene Rolle als Fehler darzustellen.
*/
await inDevlog(interaction.client, {
title: was === 'add' ? 'Whitelist: freigeschaltet' : 'Whitelist: zurückgenommen',
description:
`**${ziel.tag}** (\`${ziel.id}\`)\n` +
`Rolle: **${rolle.name}**\n` +
`Durch: **${interaction.user.tag}** (${aufruferRolle})` +
(grund ? `\nGrund: ${grund}` : ''),
color: was === 'add' ? 0x3fb950 : 0xd29922,
timestamp: new Date().toISOString(),
});
return interaction.editReply(
was === 'add'
? `${ziel.tag} hat jetzt **${rolle.name}** und kommt auf den Server.`
: `${ziel.tag} hat **${rolle.name}** nicht mehr.`
);
}
+32
View File
@@ -55,3 +55,35 @@ export async function dmAdminEinmalig(client, schluessel, zustand, embedBauen =
setSetting(merker, zustand);
return dmAdmin(client, embedBauen());
}
/**
* Ein Embed in den Devlog-Kanal.
*
* WARUM NICHT ALS DM: eine DM erreicht genau eine Person. Was das Team tut,
* gehört dorthin, wo das Team es sieht — sonst ist es protokolliert und
* trotzdem unsichtbar.
*
* WIRFT NIE. Ein fehlgeschlagener Logeintrag darf den Vorgang nicht
* mitreißen, über den er berichtet — dieselbe Regel wie bei `dmAdmin`. Der
* Rückgabewert sagt, ob es geklappt hat; wer es wissen muss, fragt ihn.
*
* @returns {Promise<boolean>}
*/
export async function inDevlog(client, embed) {
if (!config.devlogChannelId || !client) return false;
try {
const kanal = await client.channels.fetch(config.devlogChannelId).catch(() => null);
// Kein Textkanal ist kein Absturz: der Kanal kann gelöscht oder in
// eine Kategorie umgewandelt worden sein, und der Bot soll dann
// weiterarbeiten statt zu scheitern.
if (!kanal?.isTextBased?.()) return false;
await kanal.send({ embeds: [embed] });
return true;
} catch {
return false;
}
}
+42 -4
View File
@@ -74,8 +74,11 @@ async function hole(weg) {
* fehlende Quelle als „nichts gefunden" zu lesen wäre der Fehler, den diese
* Flags verhindern.
*/
export async function person(discordId) {
const a = await hole(`person?discord=${encodeURIComponent(discordId)}`);
export async function person(discordId, recht) {
// `recht` ist optional. Wird eines mitgegeben, prueft der Spielserver es
// gleich mit und legt `darf` in die Antwort - eine Frage, eine Runde.
const zusatz = recht ? `&recht=${encodeURIComponent(recht)}` : '';
const a = await hole(`person?discord=${encodeURIComponent(discordId)}${zusatz}`);
if (!a.ok) return a;
@@ -91,12 +94,47 @@ export async function person(discordId) {
* Beides wäre geraten, also wird es unterschieden.
*/
export async function darfWhitelist(discordId) {
const p = await person(discordId);
const p = await person(discordId, 'd4rk.whitelist');
if (!p.ok) return { bekannt: false, grund: p.grund };
if (p.rolleGelesen === false) return { bekannt: false, grund: 'rechtesystem_stumm' };
if (!p.rolle) return { bekannt: true, darf: false, grund: 'keine_rolle' };
if (p.rechtGelesen === false) return { bekannt: false, grund: 'recht_nicht_lesbar' };
return { bekannt: true, darf: p.darfWhitelist === true, rolle: p.rolle };
return { bekannt: true, darf: p.darf === true, rolle: p.rolle };
}
/**
* Die Einstellungen, die im Panel eingetragen sind.
*
* WARUM DER BOT SIE NICHT SELBST FUEHRT: sonst stuende die Whitelist-Rolle an
* zwei Orten. Genau daran ist die erste Fassung gescheitert — am 04.09.2026 an
* der Serverkonsole gemessen:
*
* d4rk_discord:role = "1439019849664696460,1544029550802108437"
*
* ZWEI Rollen; eingetragen war eine. Wer nur die andere hatte, kam auf den
* Server und haette hier trotzdem „Whitelist-Rolle: nein" gelesen.
*
* Der Wert kommt deshalb aus der Convar des Spielservers, durchgereicht vom
* Panel — dieselbe Quelle, die auch ueber den Zutritt entscheidet.
*
* Kurz gepuffert, damit nicht jeder Befehl eine Runde ueber das Netz macht.
* Ein Fehlschlag wird NICHT gepuffert — sonst bliebe eine Stoerung eine Minute
* lang stehen, nachdem sie vorbei ist.
*/
let konfigStand = null;
let konfigZeit = 0;
export async function konfig() {
if (konfigStand && Date.now() - konfigZeit < 30000) return konfigStand;
const a = await hole('config');
if (!a.ok) return a;
konfigStand = a;
konfigZeit = Date.now();
return a;
}