Zuletzt aktualisiert:

Runbook: PLANE_COOKIE erneuern (Plane-Relations-Session)

Symptom: app/pm/pm.sh rel … oder die Relations-/Parent-Anzeige in pm get brechen mit HTTP 401/403 — auf beiden Sessions (Mac + Strato), ohne lautes Alarm-Signal. Ursache: der Browser-Session-Cookie ist abgelaufen.

Kein Blocker. State, Priority, Assignee, Labels, Parent und Cycle laufen durabel über den öffentlichen X-API-Key (PLANE_API_TOKEN). Nur die Issue-Relations (relates_to/blocking/blocked_by/duplicate) hängen am Cookie — Plane bietet sie nur über die interne App-API an, die mit Session-Cookie + CSRF authentifiziert; der X-API-Key gibt dort 404.

Weg Auth deckt ab
Öffentliche API …/api/v1/… X-API-Key (Header) alles außer Relations (State/Prio/Assignee/Label/Parent/Cycle/Comments)
Interne API …/api/workspaces/…/issues/{id}/issue-relation/ Session-Cookie + X-CSRFToken nur Issue-Relations (Plane legt sie nicht in die /v1-API)

PLANE_COOKIE steht (gitignored, nie committen) in app/pm/.env auf beiden Maschinen. Format (eine Zeile, pm.py splittet auf das erste =):

PLANE_COOKIE=csrftoken=<CSRF>; session-id=<SESSION>

pm.py (_int_api) zieht den CSRF-Wert aus dem Cookie und setzt ihn zusätzlich als X-CSRFToken-Header. ⚠️ Der Wert enthält ; → nicht per Bash . ./.env sourcen (stolpert am ;); pm.py parst Python-seitig, das ist der einzige Konsument.

Auto-Refresh (Standard, SILV-171 — Entscheidung b)

Im Normalfall musst du nichts tun. pm.py (_int_api) loggt sich bei 401/403 automatisch neu ein und erneuert PLANE_COOKIE selbst — der Relations-Call wird danach transparent wiederholt. Voraussetzung: in app/pm/.env (gitignored, beide Maschinen) liegen die Plane-Zugangsdaten:

PLANE_EMAIL=<plane-login-mail>
PLANE_PASSWORD=<plane-login-passwort>

Mechanik (verifiziert): GET /auth/get-csrf-token/ → POST /auth/sign-in/ (Django-CSRF: Cookie csrftoken + Header X-CSRFToken + Referer/Origin, Body email/password/csrfmiddlewaretoken) → frische csrftoken+session-id-Cookies → neue PLANE_COOKIE-Zeile in .env. Manuell auslösen (Test/Vorab):

app/pm/pm.sh refresh-cookie

Manueller Fallback (falls Auto-Refresh scheitert)

Greift, wenn PLANE_EMAIL/PLANE_PASSWORD fehlen oder der Login scheitert (Passwort geändert):

  1. Im Browser bei https://pm.dennisfisch.de eingeloggt sein.
  2. DevTools → Network (oder Application → Cookies → pm.dennisfisch.de) → Request-Header Cookie: → csrftoken=… und session-id=… kopieren.
  3. In app/pm/.env die PLANE_COOKIE=-Zeile ersetzen (Format oben, unquoted, eine Zeile), beide Maschinen.
  4. Prüfen: app/pm/pm.sh rel SILV-<n>.

Warum (b) Auto-Refresh statt (a)/(c)

Quelle: SILV-171, pm-CLI-Ausbau 11.06. (pm.py _refresh_cookie/_int_api). End-to-end verifiziert: refresh-cookie + rel + Auto-Recovery aus absichtlich ungültigem Cookie (401 → Re-Login → Retry, ohne Abbruch).