Die Kanalauswahl blieb leer, obwohl "einsatzbereit" gruen daneben stand — ein
Widerspruch, der die Ursache schon verraet: der Wert lag in der Datenbank, das
Formular bekam ihn nur nie zu sehen. Ich hatte beim letzten Mal das Speichern
repariert und uebersehen, dass currentSettings() dieselbe von Hand gepflegte
Liste fuehrt. Jetzt holt auch sie die Schluessel aus dem Modul-Register.
Geheimes bleibt aussen vor: gitea_api_token steht unter requires, faellt aber
durch die Namenspruefung und wird weiterhin nur als "ist gesetzt" gemeldet.
Dazu die Uebersetzung. Im Embed standen wheat, clover_windrow und seeds, weil
der Feed nun mal Englisch spricht. Jetzt Weizen, Rotklee (Schwad) und Saatgut,
mit lesbarem Rueckfall fuer alles, was nicht in der Liste steht — 371 Sorten
uebersetzt niemand von Hand.
Und der Monat. Die zwoelf Perioden sind schlicht Monate, EARLY_SPRING ist
Maerz. Also nimmt das Feld jetzt "September", "sept" oder "9" statt
EARLY_AUTUMN; Mehrdeutiges wie "Ju" wird abgelehnt statt geraten.
Weiterzaehlen kann der Bot selbst, seit klar ist, dass ein Monat ueber einen
Tag laeuft. Nicht ueber playTime — die steht im Savegame und wird nur beim
Autosave geschrieben: ueber zwei Stunden gemessen stieg sie um 50, waehrend
die Spieluhr 18,7 Stunden weiterlief. dayTime in der Statusabfrage ist dagegen
live, und jeder Ruecksprung um Mitternacht ist ein Monatswechsel. Steht der
Server leer, steht die Spielzeit — und der Monat bleibt richtigerweise stehen.
Geprueft: alle zwoelf Monate hin und zurueck, Abkuerzungen, Monatszahlen,
Mehrdeutiges, acht Sorten Unsinn, der Jahreswechsel von Februar auf Maerz, der
Ruecksprung um Mitternacht samt Erstlauf, und dass jede Sorte der
Standardauswahl einen deutschen Namen hat.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Parzellen lagen im Wald. Ich hatte -mapSize/2 bis +mapSize/2 angenommen —
naheliegend beim Namen, aber falsch: die Koordinaten laufen von -mapSize bis
+mapSize. Damit wurde jede Parzelle um Faktor zwei vom Mittelpunkt weggezogen.
Schlimmer als der Fehler war meine Pruefung. Der Zonentest hat die Koordinaten
auf ihre eigene Bounding-Box normiert und danach geschaut, ob die Felder in der
richtigen Ecke liegen. Das besteht bei JEDEM Massstab, weil die Anordnung
zueinander ja stimmt. 14 von 15 Treffern klangen ueberzeugend und sagten
ueber den Massstab genau nichts aus.
Gemessen wurde es dann so: die eingebrannte Legende steht sowohl im Feed-Bild
als auch im Ingame-Screenshot, damit laesst sich der eine aufs andere
umrechnen. Vier Parzellen an den vier Ecken ergaben eine Weltbreite von 7822
bei mapSize 4096 — Faktor 1,91 bei rund 5 Prozent Ablesegenauigkeit.
Dabei ist noch etwas herausgekommen: die Marken H1..H8 auf dem Luftbild sind
als Passpunkte hervorragend, nicht wertlos, wie ich in der Doku behauptet
hatte. Mit richtigem Massstab liegen alle acht Hofparzellen unter 13 px von
ihrer Marke; mit falschem rund 200. Das ist jetzt der Test — acht Passpunkte,
die jede kuenftige Verschiebung sofort auffliegen lassen, statt eines
Zonenvergleichs, der alles durchwinkt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Feed eines LS-Servers gibt viel mehr her als die Spielerzahl, die der
Monitor bisher davon benutzt hat: in denselben 49 KB stehen 163 Parzellen mit
Besitzer und Hektar, 130 Felder, jedes Fahrzeug samt Ladung und die Position
jedes Spielers. Und das Luftbild liefert der Server auch, in jeder Groesse bis
4096.
Also eine Karte: gekaufte Parzellen nach Hof eingefaerbt, Kreisflaeche gleich
Hektar, Fahrzeuge und Spieler live, dazu eine Hof-Uebersicht mit Flaeche und
Wert. Wechselt Land den Besitzer, kommt eine Meldung — beim allerersten
Durchlauf bewusst nicht, sonst haette der Botstart eine Meldung pro bereits
gekaufter Parzelle abgesetzt.
Dazu die Preiskurven aus der economy.xml: je Fruchtart, was sie in welcher der
zwoelf Perioden bringt, als Balkenzeile mit "jetzt verkaufen" oder "+43 Prozent
im Hochwinter".
Was NICHT geht, und zwar grundsaetzlich: welche Frucht auf welchem Feld steht
und wie weit sie ist. Das liegt in einer binaeren Density-Map, die kein
Endpunkt herausgibt. Ich habe 18 Dateinamen durchprobiert, es gibt genau drei.
Die Mods, die das anzeigen, sind reine HUD-Overlays ohne Ausgang. Und keiner
der fuenf anderen LS-Bots kann es, obwohl einer davon Geld kostet. Das steht
mit allen Belegen in docs/ls-feed.md, damit die Frage nicht dreimal kommt.
Beim Bauen aufgefallen:
- istLsServer() gab den Zugangs-Code zurueck statt true — die &&-Kette liefert
den letzten wahren Wert. Beim ersten Log-Aufruf haette der Code im Klartext
im Protokoll gestanden.
- Die Karte als PNG war 2,5 MB, als JPEG 268 KB. Es ist ein Luftbild.
- Nach Preisschwankung sortiert gewinnt Spargel: 26 bis 7540 Euro, und Weizen
taucht gar nicht mehr auf. Die Liste arbeitet jetzt mit einer Auswahl.
- Die Jahreszeit steht in keinem Endpunkt. Schaetzbar waere sie, aber nur
solange niemand die Zeitskala aendert — also eine Einstellung.
Geprueft gegen echte Serverdaten: Zerlegen der Statusabfrage inklusive
Vollstaendigkeit aller 163 Parzellen, Ladung ohne Diesel und leere Slots,
Hof-Uebersicht ohne verlorene Parzellen, Preiskurve mit vollem und leerem
Balken an der richtigen Stelle, flache Kurve ohne Division durch Null,
Besitzwechsel inklusive Erstlauf und neu hinzugekommener Parzelle,
Hof-Namen aus der Einstellung, SVG ohne NaN und mit maskierten Namen, und der
Merker in der Datenbank inklusive kaputtem JSON.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LS25 fehlte, aber nicht nur LS25: die Auswahl im Panel war eine von Hand
gepflegte Liste mit neunzehn Eintraegen, und fuenf davon gab es bei gamedig
gar nicht — "arkse", "ark", "sevendaystodie", "minecraftbe" und "terraria".
Wer eines davon auswaehlte, bekam einen Server, der dauerhaft offline stand,
ohne dass irgendwo ein Grund stand. Die echten IDs heissen ase, sdtd, mbe und
terrariatshock.
Also nicht LS25 nachtragen, sondern die Liste abschaffen: sie kommt jetzt aus
gamedig selbst, 360 Eintraege, sortiert, mit Suche. Jedes Update bringt neue
Spiele automatisch mit. Dazu der Standard-Query-Port als Vorschlag, sobald man
ein Spiel waehlt. Bestehende Eintraege mit den toten IDs werden beim Start
einmalig umgebogen.
Farming Simulator hat noch eine zweite Huerde: der Server antwortet nur mit
Zugangs-Code, und den hat queryServer nie durchgereicht. LS25 waere also auch
mit richtiger ID offline geblieben. Jetzt gibt es eine Spalte dafuer, das Feld
erscheint nur bei Spielen, die einen brauchen (Farming Simulator, Terraria —
bei Satisfactory optional), und Speichern ohne Code wird abgelehnt statt
stillschweigend hingenommen. Der Code steht nicht in der oeffentlichen API.
Nebenbei aufgefallen: input[type=password] war im CSS nirgends erfasst. Das
erste solche Feld kam voellig ungestylt daher.
Die /server-Seite dazu:
- Auslastungs-Balken mit eigener Farbe statt des XP-Balkens vom Level-System.
Gruen frei, gelb ab 80 Prozent, rot voll — die Zahl steht rechtsbuendig,
mittig laege sie bei 50 Prozent genau auf der Fuellkante.
- Map, Version und Ping als Chips. Vorher standen sie mit Punkten getrennt in
der Statuszeile und wurden auf dem Handy zu Brei.
- Wer gerade drauf ist. Die Namen holt der Monitor ohnehin schon fuers Embed,
auf der Seite standen sie nur nirgends.
- Welches Spiel es ueberhaupt ist. Das stand nirgends ausser im Emoji.
- Offline-Karten waren bisher leer bis auf das Wort. Jetzt steht dort, seit
wann — soweit der Verlauf reicht, sonst gar nichts statt einer Schaetzung.
- Zeitachse und Peak-Linie am Verlauf. Eine Flaeche ohne Bezugspunkt sagt
nicht, wie hoch hoch ist.
- Plaetze insgesamt in der Uebersicht oben.
Geprueft: Token speichern und aendern, Spielnamen inklusive unbekannter ID,
Token-Bedarf pro Protokoll, Liste ohne Doppler, alle Icon-Schluessel gegen
gamedig, "zuletzt online" ignoriert Offline-Proben, und die Migration mit einer
Datenbank im alten Stand. Beide Seiten am laufenden Frontend angesehen, auch
auf Handybreite.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Funktionsliste war eine einzige Tabelle mit 46 Zeilen — in der Reihenfolge,
in der die Sachen entstanden sind, also in keiner. Jetzt ist sie nach denselben
Bereichen sortiert wie das Panel: Inhalte, Community, Moderation, Server, dazu
Plattform fuer alles, was keine Discord-Funktion ist. Wer im Panel etwas sucht,
findet den Abschnitt in der README am selben Platz.
Nachgetragen, was seither dazugekommen ist: AutoMod, Raid-Schutz, verknuepfte
Rollen, native Umfragen, Statusseite, Herzschlag, Seiten-Editor, Englisch fuer
die oeffentlichen Seiten. Und die Trennung in zwei Domains stand bisher gar
nicht drin, obwohl sie das Erste ist, was man verstehen muss — sie steht jetzt
ganz oben, mit einer Tabelle welche Seite was zeigt.
Korrigiert: 35 Module waren es mal, es sind 39. 15 Config-Bereiche waren es
mal, es sind 16. Die Seitentabelle fuehrte Hub-Seiten unter der Bot-Domain.
Die Projektstruktur kannte die Haelfte der Dateien nicht. In der
Ersteinrichtung fehlten die Rechte fuer AutoMod und Kanal-Anlegen sowie die
zusaetzlichen OAuth-Redirects.
Dazu ein Inhaltsverzeichnis, eine docs/README.md als Wegweiser, und in
konzept-zwei-seiten.md steht nicht mehr "muss noch aktiviert werden" — es
laeuft seit Ende Juli.
Geprueft mit einem kleinen Skript: 11 Markdown-Dateien, keine toten
Datei-Links, keine toten Anker, keine Tabelle mit falscher Spaltenzahl.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bewusst Discords eigenes Poll-Objekt statt einer Nachbildung mit Knoepfen —
Oberflaeche, Auszaehlen und Ergebnisanzeige macht Discord dann selbst, auch
auf dem Handy. Wir bauen nur die Frage zusammen.
Bis zu vier Antworten (Discord erlaubt zehn, vier halten den Befehl
uebersichtlich), Laufzeit von einer Stunde bis einer Woche, Mehrfachauswahl
optional. Rechte: ManageMessages.
Zwei gleiche Antworten werden abgefangen. Discord stoert das nicht, aber
abstimmen kann darauf niemand sinnvoll.
Nicht zu verwechseln mit /wunsch: das sammelt Feature-Wuensche dauerhaft und
zeigt sie auf der Roadmap. /umfrage ist die schnelle Frage zwischendurch und
laeuft von selbst ab. Steht so auch als Kommentar im Befehl.
Geprueft gegen die installierte discord.js-Fassung (14.27) statt gegen die
Dokumentation: Feldnamen aus den Typdefinitionen gelesen, und die fertige
Nutzlast durch discord.js' eigene Serialisierung gejagt. Kommt als
poll_media / allow_multiselect / layout_type 1 raus, genau wie Discords API
es erwartet.
Dazu: 18 Befehle laden ohne Namenskollision, Befehl steht auf der
oeffentlichen Liste in beiden Sprachen, Zahl auf der Produktseite von 17
auf 18.
Nutzungsbedingungen als Entwurf unter docs/ — Text fuer den Seiten-Editor,
keine Rechtsberatung.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zwei Stellen, an denen die Marke bisher fehlte.
Willkommens-Karte: Das Wasserzeichen war der Markenname als Text mit 5 %
Deckkraft — jetzt der Katzenkopf. Die Datei wird einmal beim Start gelesen
statt bei jedem Beitritt, und fehlt sie, rendert die Karte wie bisher ohne
Wasserzeichen. Der Schalter heisst entsprechend "Logo im Hintergrund".
Link-Vorschau: og:image war nur gesetzt, wenn ein Devlog einen Screenshot
hatte. Startseite, Roadmap, Funktionen und jedes Devlog ohne Bild kamen in
Discord als graue Textzeile. Jetzt faellt alles ohne eigenes Bild auf
og-default.png zurueck (1200x630, Lockup auf Schwarz mit Akzentstreifen),
und twitter:card ist durchgehend summary_large_image.
Die Laufzeit-Datei liegt unter src/bot/assets/, nicht in docs/ — das
Dockerfile kopiert nur src/ und frontend/dist/.
Geprueft: librsvg zeichnet das eingebettete <image> wirklich (42726 Pixel
unterscheiden sich gegen eine Fassung ohne), das OG-Bild landet im dist.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zwei Korrekturen am vorigen Commit:
- Ich hatte das Maskottchen durchgehend als Wolfskopf beschrieben. Es ist eine
Katze. Betrifft README und die Kommentare in build.py.
- Gitea setzt neben favicon.svg noch ein <link rel="alternate icon"> auf
favicon.png. Die Datei fehlte, dort stand also weiter die Gitea-Tasse —
am Livesystem geprueft, das Bild kam in Gitea-Gruen (96,153,38) zurueck.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Das Logo lag bisher nirgends im Einsatz — das Favicon war ein handgeschriebenes
Prisma in Gold/Orange, das Wasserzeichen der Willkommens-Karte der blosse
Markenname als Text.
- docs/brand/ mit lockup.png (volles Logo) und mark.png (nur der Wolfskopf)
plus build.py, das beide und alle abgeleiteten Icons erzeugt
- frontend: favicon.svg ersetzt, apple-touch-icon.png dazu und verlinkt
- Zwei Fassungen, weil das Lockup bei 16 px zu einem orangen Balken wird; der
Kopfzuschnitt wurde gegen drei Varianten geprueft
- SVG mit eingebettetem PNG statt Vektorisierung: das Original hat Verlaeufe
und Schattierung, nachgezeichnet wuerde es matschen
- Die Icons auf dunklem Grund sind deckend, sonst legt iOS hinter transparente
Lesezeichen Schwarz oder Weiss und der Wolf ist selbst fast schwarz
Geprueft: beide Dateien werden mit korrektem MIME-Typ ausgeliefert und das SVG
rendert wirklich (128x128), die Link-Tags stehen im gebauten HTML.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Text für den Devlog-Post über hub.d4rkst3r.de: eigene Adresse, Wegweiser
zwischen Hub und Bot-Seite, die neuen Eingabefenster bei /bug und /wunsch,
frei angelegte Seiten. Bilder liegen unter A:\eco\devlog-hub-bilder.
Bewusst ohne Wiederholung des Posts von heute früh — Startseite,
Server-Verlauf, Profil und Willkommens-Karten stehen dort schon.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
/features zeigte bisher dieselbe Landing wie /, obwohl die Navigation und
ein Knopf auf der Startseite eine echte Funktionsliste versprachen.
Die Seite listet jetzt alle 35 Bot-Funktionen, nach denselben Gruppen
sortiert wie im Panel, dazu sechs Punkte zum Drumherum (Webinterface,
Texte, API/SSO, eigene Seiten, Team-Rechte, Betrieb).
Die Einträge kommen über das neue öffentliche /api/features aus
src/modules.js — derselben Quelle, aus der die Modul-Schalter kommen. Eine
neue Funktion erscheint damit automatisch auf der Produktseite, statt dass
jemand daran denken muss. Der Endpunkt gibt bewusst nur Name, Beschreibung
und Gruppe heraus, nicht welche Module hier gerade laufen.
Auch die Zahl auf der Startseite kommt von dort, damit nicht zwei Stellen
dieselbe Zahl pflegen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Die Seite hieß Setup und listete 15 Bereiche flach untereinander. Wer
nicht wusste, dass Geburtstage unter „Community" stecken und Willkommens-
Texte unter „Support", hat geklickt bis er es fand.
Die Seitenleiste gruppiert jetzt nach Überblick, Auftritt, Inhalte,
Community, Technik und Zugang. Darüber steht ein Suchfeld, das nicht nur
Beschriftungen durchsucht, sondern auch Stichwörter je Bereich — „geburtstag"
führt zu Community, „ticket" zu Support. Enter springt zum ersten Treffer.
Der aktive Bereich steht in der Adresse (/settings#texte). Damit überlebt er
das Neuladen, und man kann jemandem einen Link auf genau die Stelle schicken.
Der Status-Bereich war die leerste Seite im ganzen Panel: sechs Zahlen. Er ist
jetzt der Einstieg und beantwortet die Frage, die man beim Öffnen wirklich hat
— was läuft noch nicht? Eingeschaltete Module, denen ein Kanal oder eine Rolle
fehlt, stehen dort mit einem Knopf, der direkt an die richtige Stelle springt.
Ist alles eingerichtet, sagt die Seite genau das.
Umbenannt in „Config", weil „Setup" nach einmaliger Einrichtung klingt — die
Seite ist aber der Ort, an dem man dauerhaft alles einstellt.
Schmale Bildschirme: die Leiste wird zur umbrechenden Zeile ohne
Gruppen-Überschriften, das Suchfeld nimmt die volle Breite.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Eine Anwendung, zwei Gesichter — der Server erkennt an der Domain, welche
Seite gefragt ist, und schreibt das als data-site an den <body>. Das
Frontend rendert daraufhin entweder den Community-Hub wie bisher oder die
neue Produktseite.
- Bot-Produktseite (BotApp): Landing mit Feature-Übersicht, Befehls-
referenz, Dashboard unter /dashboard, Orange als Leitfarbe
- Weiterleitungen: Community-Routen auf der Bot-Domain und umgekehrt
werden dauerhaft (301) auf die richtige Adresse geschickt — geteilte
Devlog-Permalinks laufen also nicht ins Leere. Rechtstexte bleiben auf
beiden erreichbar.
- Open-Graph-Tags je Domain, inklusive eigener Vorschau für frei
angelegte Seiten (Entwürfe bekommen bewusst keine)
- Login: neue Einstellung für die Cookie-Domain, damit die Anmeldung auf
beiden Seiten gilt; nach dem Discord-Login landet man wieder auf der
Seite, von der man gestartet ist (vorher immer auf der Hauptadresse)
- Alles greift erst, wenn beide Adressen im Setup eingetragen sind —
bis dahin verhält sich die Anwendung unverändert
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Kein Einladen-Button: der Bot bleibt auf einen Server ausgelegt, die
Produktseite ist Visitenkarte und Dashboard
- /commits gehört auf den Hub (Projekt-Entwicklung, keine Bot-Verwaltung)
- Bot-Seite bekommt Orange als Leitfarbe statt Gelb — gleiche Marke,
aber beim Domainwechsel sofort erkennbar
- Statt des gewünschten Forums (Burning-Board-Stil) ein Seiten-Editor:
ein Forum neben aktivem Discord verwaist erfahrungsgemäß und bringt
Moderationsaufwand; der eigentliche Wunsch — Inhalte ohne Commit
pflegen zu können — wird mit frei anlegbaren Markdown-Seiten erfüllt
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Entwurf zur Abstimmung, noch nichts umgesetzt: Seitenstruktur beider
Domains, Host-Routing statt zweitem Deployment, geteilter Login über
.d4rkst3r.de, Weiterleitungen für alte Permalinks, zwei URL-Einstellungen
statt einer.
Enthält auch die Abwägung zur Repo-Frage: getrennte Repositories würden
bedeuten, dass der Hub für alles, was heute direkter Zugriff ist
(Rollen holen und setzen, Wünsche posten, Monitor-Ergebnisse, Devlogs,
Level), HTTP-Schnittstellen zum Bot braucht — die Web-API nutzt an 33
Stellen den laufenden Discord-Client. Vorschlag stattdessen: ein Repo mit
getrennten Frontend-Ordnern (shared/hub/bot) und zwei Builds.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
In Gitea ist fast jeder Text ein Link (a { color: var(--color-primary) }),
eine Aktivitätsseite besteht praktisch nur daraus. Das volle #f5c518 hat
90 % Sättigung — als Akzent gedacht, nicht für Fließtext, und blendet
entsprechend.
Links, Flächen und Tönungen nutzen jetzt ein entsättigtes Gold (#dcc275,
47 % Sättigung, Kontrast 11:1 auf Schwarz). Das Neon bleibt den Stellen
vorbehalten, wo es wirken soll: Primär-Buttons, aktive Navigation und
Hover — Links leuchten also erst auf, wenn man draufzeigt.
Die Abstufungen (dark-1..7, light-1..7) sind passend zur neuen Basis neu
berechnet. Oben in der Datei steht, wie sich die Intensität nachjustieren
lässt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Repo-Backups: nachts um 04:00 werden alle Gitea-Repos als git-Bundle
gesichert — eine Datei pro Repo mit kompletter Historie, aus der sich
direkt wieder klonen lässt. 14 Tage Rotation wie beim DB-Backup,
Schalter und "Repos jetzt sichern" im System-Tab. Nutzt den bereits
vorhandenen Gitea-Token; Dockerfile installiert dafür git mit.
- Gitea-Theme im D4RKST3R-Look (docs/gitea-theme/): Neon-Gelb/Orange auf
Schwarz, gebaut gegen die Variablen von Gitea 1.26, Diff-Farben bleiben
lesbar. Einbau-Anleitung liegt daneben.
- Auto-Deploy statt manuellem "Pull and redeploy": Workflow für Gitea
Actions (prüft Server-Syntax und Frontend-Build, bevor deployed wird)
plus dokumentierter Runner-loser Weg über den Portainer-Webhook.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Dienste (Gitea, Kanban, Cloud …) werden im System-Tab gepflegt und
erscheinen als Kacheln auf der Startseite; GET /api/services ist
öffentlich, Pflege braucht den settings-Scope
- /brand.css liefert die Design-Tokens (Farben live aus dem Brand-Tab,
ändern sich damit überall mit) plus Basis-Klassen d4rk-card,
d4rk-btn, d4rk-title, d4rk-tag
- /brand-nav.js baut die D4RKST3R-Leiste in jede fremde App ein, mit
Links zum Hub und zu allen gepflegten Diensten; die Links stecken
fertig im Skript, dadurch kein zweiter Request und kein CORS nötig
- Beide Dateien mit offenem CORS-Header und 5 Minuten Cache
- Doku für Anbindung + Schriften in docs/sso.md ergänzt
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Andere Apps (Kanban, Platform …) nutzen ab sofort den Discord-Login des
Bots mit, statt jeweils eigenes OAuth zu bauen — und bekommen die
Discord-Rollen des Users gleich mitgeliefert.
Ablauf: App leitet auf /sso/authorize weiter, der Bot prüft die Session
(ggf. erst Discord-Login) und schickt einen signierten Token zurück, den
die App serverseitig per POST /sso/verify gegen die Nutzerdaten tauscht.
Sicherheit:
- Rücksprung-Ziele müssen einem registrierten Präfix entsprechen
(kein Open Redirect, kein Token-Abgriff über fremde Hosts)
- Token HMAC-signiert, 60 Sekunden gültig, nur einmal einlösbar
- Verify braucht das App-Secret (timing-safe verglichen)
- SSO bleibt Mitgliedern des Discord-Servers vorbehalten
- App-Verwaltung ist Owner-only, Secret wird nur einmal angezeigt
Dazu: sso_apps-Tabelle, Verwaltung im API-Tab, Rücksprung nach dem
Login (return-Cookie, nur interne Pfade), Anleitung in docs/sso.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
D4rkst3randClaude Opus 5