sascha/tdarr
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tdarr/fileflows/guard
History
Trulla 18e123bdb2 Add FileFlows ApiKey guard against [REDACTED] key corruption 
Die FileFlows-API liefert ApiKey-Felder im GET als [REDACTED]. Ein Save aus
der Web-UI (oder GET->PUT-Roundtrip) schreibt diesen Platzhalter in die DB,
wodurch alle vier Arr-Manual-Import-Nodes still mit 401 fehlschlagen. Der
n8n-Handoff bleibt auf processing, movetdarr.sh pollt weiter und der
SAB-Job haengt bis zum 24h-Timeout in der Queue.

Negativtest bestaetigt: ein sabotierter Key korrumpiert alle vier, weil der
GET alle vier als [REDACTED] ausliefert.

Guard prueft die FileFlows-SQLite auf ApiKeys != 32 Zeichen und schreibt die
echten Keys via Butler-Proxy zurueck. Laeuft als systemd-Timer alle 15min
auf tdarr (cron dort inaktiv).
2026-09-16 11:34:22 +02:00
..
ff-apikey-guard.sh Add FileFlows ApiKey guard against [REDACTED] key corruption 2026-09-16 11:34:22 +02:00
README.md Add FileFlows ApiKey guard against [REDACTED] key corruption 2026-09-16 11:34:22 +02:00

README.md

FileFlows ApiKey Guard

Problem

Die FileFlows-API liefert ApiKey-Felder in Flow-Parts beim GET grundsätzlich als Literal [REDACTED] aus. Wird ein Flow danach gespeichert — aus der Web-UI oder über einen GET → PUT-Roundtrip (Scripts, Automationen) — landet dieser Platzhalter in der Datenbank.

Folge: die Nodes Sonarr - Trigger Manual Import und Radarr - Trigger Manual Import authentisieren sich mit [REDACTED], die Arr antwortet 401, der Node bricht still ab.

Fehlerbild in der Kette:

SABnzbd (movetdarr.sh) → FileFlows → Arr Manual Import
                                     ↑ 401, still
  • n8n Media-Handoff bleibt auf processing stehen
  • movetdarr.sh pollt den Handoff-Lease weiter → SAB-Job hängt in der Queue bis zum 24-h-Timeout
  • Symptom beim Nutzer: "hängt seit Stunden in der Queue"

Ein einziger UI-Save zerschießt alle vier Keys gleichzeitig, weil der GET alle vier als [REDACTED] ausliefert (verifiziert per Negativtest: 1 Key sabotiert → 4 Keys in der DB defekt).

Lösung

ff-apikey-guard.sh prüft alle Flows in der FileFlows-SQLite auf ApiKeys mit Länge != 32 und schreibt die echten Keys via Butler-Proxy (PUT /fileflows/api/flow) zurück.

Keys kommen aus einer lokalen Map, nie aus Git.

Deployment (tdarr, 10.2.1.104)

sudo install -m 750 fileflows/guard/ff-apikey-guard.sh \
    /app-config/ff-guard/ff-apikey-guard.sh

# Butler-Token
printf '%s' '<butler-token>' | sudo tee /app-config/ff-guard/butler.token
sudo chmod 600 /app-config/ff-guard/butler.token

# Key-Map: "<port> <apikey>" pro Zeile, Keys aus den Arr-config.xml auf 10.2.1.100
#   8989 sonarrUHD / 8990 sonarrFHD / 7878 radarrUHD / 7879 radarrFHD
sudo chmod 600 /app-config/ff-guard/arr-keys.map

Läuft als systemd-Timer alle 15 Minuten (cron ist auf tdarr inaktiv):

/etc/systemd/system/ff-apikey-guard.service   Type=oneshot
/etc/systemd/system/ff-apikey-guard.timer     OnUnitActiveSec=15min

sudo systemctl enable --now ff-apikey-guard.timer

Betrieb

# Log
sudo tail /app-config/ff-guard/guard.log

# Manuell prüfen/reparieren
sudo systemctl start ff-apikey-guard.service

# Timer-Status
systemctl list-timers ff-apikey-guard.timer

Logzeilen (Datum TT.MM.JJJJ):

  • OK: alle Flow-ApiKeys 32 Zeichen — nichts zu tun
  • WARNUNG: defekte ApiKeys in Flow <uid> — repariere
  • Flow <uid> repariert: N Key(s) zurueckgeschrieben (HTTP 200)

Nach einem UI-Save immer prüfen

Wer einen Flow in der FileFlows-UI speichert, sollte danach den Guard anstoßen oder maximal 15 Minuten auf den Timer warten. Vorher schlagen alle Arr-Importe still fehl.