offenen Weiterleiter haerten — Sperrliste, Rate-, Zeit- und Groessen-Deckel
Gemessener Ausgangszustand (2026-08-22): POST /api/playground/proxy war OHNE
Anmeldung nutzbar, OHNE Rate-Begrenzung, OHNE Zeitlimit und OHNE Groessen-Deckel,
und liess JEDE .ayoune.app-Unterdomaene zu — su-api (Superuser/godfather, laut
Wurzel-CLAUDE.md ausdruecklich nie aus Kunden-Clients), credentials-api
(Zugangs-Tresor) und registry (private Paket-Registry) eingeschlossen. Der
Weiterleiter verbarg dabei die Herkunfts-Adresse des Aufrufers hinter der
Pod-Adresse.
Der Riegel liegt in der REINEN Funktion checkPlaygroundTarget (kein Express,
kein Netz, kein Zustand) — nur so ist er ohne laufenden Dienst pruefbar:
- Sperrliste privilegierter Wirte, ausgewertet VOR der Nachsilben-Pruefung
(sonst faellt su-api durch das -api-Muster wieder herein)
- Anmeldedaten in der Adresse abgewiesen (verschiebt, was ein Mensch LIEST,
ohne zu aendern, wohin die Anfrage GEHT)
- ausdruecklicher Port abgewiesen (sonst Port-Abtaster fuer alles unter der
Nachsilbe); der Regel-Port bleibt erlaubt
- Rate-Begrenzung 20/min je Herkunft ueber das vorhandene checkRateLimit
- Zeitlimit 10 s und Antwort-Deckel 512 KiB; redirect manual, weil eine
Umleitung aus einem erlaubten Wirt einen gesperrten machen koennte, NACHDEM
die Pruefung gelaufen ist
Verify: npm run build Ende 0 / 0 TS-Fehler; neue Reihe 19/19; volle Reihe des
Repositoriums 1632/1632, 0 Fehler. Die Reihe traegt drei FLIP-PROBEN, die die
alte Regel woertlich nachbauen und belegen, dass sie genau diese Faelle
durchliess — samt Gegenkontrolle, dass das regulaere Ziel crm-api.ayoune.app
bei BEIDEN Regeln durchgeht, der Playground also nicht gebrochen ist.
Brief: api-lieferwege-playground-und-livemap (Punkt 5).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2uHkCzw3A1XWKSCf6c7JF
Anmeldung nutzbar, OHNE Rate-Begrenzung, OHNE Zeitlimit und OHNE Groessen-Deckel,
und liess JEDE .ayoune.app-Unterdomaene zu — su-api (Superuser/godfather, laut
Wurzel-CLAUDE.md ausdruecklich nie aus Kunden-Clients), credentials-api
(Zugangs-Tresor) und registry (private Paket-Registry) eingeschlossen. Der
Weiterleiter verbarg dabei die Herkunfts-Adresse des Aufrufers hinter der
Pod-Adresse.
Der Riegel liegt in der REINEN Funktion checkPlaygroundTarget (kein Express,
kein Netz, kein Zustand) — nur so ist er ohne laufenden Dienst pruefbar:
- Sperrliste privilegierter Wirte, ausgewertet VOR der Nachsilben-Pruefung
(sonst faellt su-api durch das -api-Muster wieder herein)
- Anmeldedaten in der Adresse abgewiesen (verschiebt, was ein Mensch LIEST,
ohne zu aendern, wohin die Anfrage GEHT)
- ausdruecklicher Port abgewiesen (sonst Port-Abtaster fuer alles unter der
Nachsilbe); der Regel-Port bleibt erlaubt
- Rate-Begrenzung 20/min je Herkunft ueber das vorhandene checkRateLimit
- Zeitlimit 10 s und Antwort-Deckel 512 KiB; redirect manual, weil eine
Umleitung aus einem erlaubten Wirt einen gesperrten machen koennte, NACHDEM
die Pruefung gelaufen ist
Verify: npm run build Ende 0 / 0 TS-Fehler; neue Reihe 19/19; volle Reihe des
Repositoriums 1632/1632, 0 Fehler. Die Reihe traegt drei FLIP-PROBEN, die die
alte Regel woertlich nachbauen und belegen, dass sie genau diese Faelle
durchliess — samt Gegenkontrolle, dass das regulaere Ziel crm-api.ayoune.app
bei BEIDEN Regeln durchgeht, der Playground also nicht gebrochen ist.
Brief: api-lieferwege-playground-und-livemap (Punkt 5).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2uHkCzw3A1XWKSCf6c7JF