Middleware cloudflare-only (ipAllowList: Cloudflare-IPs und private Netze)
vor die HTTPS-Umleitung gesetzt, wie live im Cluster seit 2026-10-12.
Direkte Zugriffe auf den Origin an Cloudflare vorbei bekommen 403.
Die Middleware selbst liegt in rke2-cluster/security.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Die Manifeste in k8s/ trugen noch Platzhalter, waehrend im Cluster laengst
die echten Werte stehen. Wer sie unveraendert anwendet, ueberschreibt damit
funktionierende Einstellungen.
- Domain: shop.example.com -> wabenhain.com, in 06-ingress.yaml (host und
tls.hosts) und in 01-configmap.yaml (NEXT_PUBLIC_SITE_URL). Beide Stellen
muessen uebereinstimmen; aus NEXT_PUBLIC_SITE_URL entstehen Sitemap,
Canonical-Tags und jeder Link in jeder Bestellbestaetigung.
- GOOGLE_PLACES_API_KEY von der ConfigMap ins Secret. Das ist ein
abrechenbarer Zugangsschluessel, und eine ConfigMap ist unverschluesselt
und in der Cluster-Oberflaeche im Klartext lesbar. Die zugehoerige
GOOGLE_PLACE_ID ist oeffentlich und bleibt in der ConfigMap. Der Cluster
handhabt das bereits so.
- APICORE_API_URL vom Secret in die ConfigMap: eine Adresse ist kein
Geheimnis. Auch das entspricht dem Cluster.
- VIDEO_TRANSCODE_THREADS in die ConfigMap aufgenommen, damit die
Threadbegrenzung des Video-Transcodes (siehe vorheriger Commit) auch ueber
das Deployment einstellbar ist.
Gegenprobe: die Vereinigung aller Schluessel aus ConfigMap und Secret deckt
jetzt genau die Umgebungsvariablen ab, die der Code ueber process.env liest
- keine fehlt. Die beiden Ueberhaenge sind beabsichtigt: DB_PASSWORD liest
der Postgres-StatefulSet, STRIPE_PUBLISHABLE_KEY haelt die Konfiguration
vollstaendig fuer eine kuenftige clientseitige Stripe-Einbindung.
Der Hinweistext der Go-Live-Pruefung nannte shop.example.com als
ausgelieferte Vorgabe; das stimmt nicht mehr. Die Pruefung selbst ist
unveraendert.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Der Zielcluster nutzt Traefik, nicht ingress-nginx. Saemtliche Annotationen
der Form nginx.ingress.kubernetes.io/* ignoriert Traefik ersatzlos und
still: sie erzeugen keinen Fehler, wirken aber auch nicht. Das betraf das
Upload-Limit (proxy-body-size) ebenso wie die Zeitlimits, und
ingressClassName zeigte auf "nginx".
Damit aendert sich auch die Diagnose des fehlgeschlagenen Video-Uploads.
Belegt aus Traefiks Quelltext (pkg/config/static/static_config.go,
SetDefaults) und der Referenzdokumentation:
- readTimeout des EntryPoints: Default 60s, beschrieben als "maximum
duration for reading the entire request, including the body". Er umfasst
also die gesamte Uebertragung des Uploads. Bei 20-100 MB ueber eine
normale Upload-Leitung ist das schnell ueberschritten — 80 MB bei
10 Mbit/s sind rund 64 Sekunden. Laeuft er ab, kappt Traefik die
Verbindung und antwortet mit einer eigenen HTML-Fehlerseite. Das ist die
wahrscheinlichste Quelle des "Unexpected token '<'" im Browser.
- responseHeaderTimeout: von SetDefaults NICHT gesetzt, bleibt 0, und
"If zero, no timeout exists". Die Dauer des ffmpeg-Transcodings ist bei
Traefik also NICHT begrenzt — anders als zuvor angenommen.
- Body-Groesse: Traefik erzwingt keine Obergrenze (begrenzt ist nur
maxHeaderBytes mit 1 MB fuer die Header). Ein Gegenstueck zu nginx'
proxy-body-size wird nicht gebraucht.
readTimeout gehoert zur statischen EntryPoint-Konfiguration und laesst sich
nicht per Ingress-Annotation setzen. Das Manifest dokumentiert deshalb
ausfuehrlich, welche Einstellung in der Traefik-Installation noetig ist
(Helm: ports.websecure.transport.respondingTimeouts.readTimeout: 600s).
Weiter angepasst: ingressClassName auf "traefik", HTTPS-Umleitung ueber eine
Traefik-Middleware statt der nginx-Annotation, und der Hinweis zu
X-Forwarded-For nennt jetzt Traefiks forwardedHeaders.trustedIPs — davon
haengt ab, ob lib/rate-limit.ts dem Header trauen darf. Die Kommentare in
lib/uploads.ts und lib/csrf.ts verwiesen auf die entfernten
nginx-Einstellungen und sind entsprechend berichtigt.
Zwei Einstellungen im Deployment liessen einen Video-Upload scheitern,
bevor die Anwendung ueberhaupt antworten konnte — beide Male mit einer
HTML-Fehlerseite, die im Browser als "Unexpected token '<'" ankam:
1. Der Ingress trug keinerlei Timeout-Annotation. ingress-nginx wartet
dann nur 60 Sekunden je Phase und liefert danach eine eigene
HTML-504-Seite. Ein Video-Upload braucht regelmaessig laenger: erst
muessen bis zu 100 MB ueber die Leitung, danach rechnet ffmpeg das
Video fuers Web um. proxy-read-timeout und proxy-send-timeout stehen
jetzt auf 600s — bewusst oberhalb des harten ffmpeg-Zeitlimits von 5
Minuten, damit im Zweifel die Anwendung selbst mit einer verwertbaren
JSON-Meldung abbricht statt nginx die Verbindung zu kappen.
2. Das Speicherlimit von 512Mi war fuer einen 100-MB-Upload zu knapp:
request.formData() laedt den multipart-Body vollstaendig in den
Speicher, und der Kernel beendet den Prozess bei Ueberschreitung
(OOMKilled). Limit auf 1Gi, Request auf 512Mi. Der CPU-Request steigt
von 100m auf 500m, weil ffmpeg CPU-gebunden ist und mit 100m ein
Vielfaches der Zeit braucht — bewusst weiterhin ohne CPU-Limit, das
wuerde den Transcode auch auf einem freien Knoten drosseln.
Der Kommentar nennt zusaetzlich das davon unabhaengige Origin-Zeitlimit
eines vorgeschalteten CDN (bei Cloudflare 100 Sekunden, Fehler 524), das
sich hier nicht beeinflussen laesst.
Vier Befunde aus der Pruefung der Upload-Kette, alle am gemeinsamen
Datenpfad lib/uploads.ts und app/uploads/[...path]/route.ts:
1. Kein Range-Support. Die Ausliefer-Route beantwortete auch einen
Range-Request mit einer vollstaendigen 200-Antwort. Ein <video> laedt
sein Material grundsaetzlich per Range; iOS-Safari schickt zuerst die
Probe "bytes=0-1" und spielt bei einer 200-Antwort gar nicht ab.
Springen im Hero-Video war ebenfalls unmoeglich. Die Route beantwortet
Bereichsanfragen jetzt mit 206 samt Content-Range, meldet
Accept-Ranges und antwortet auf einen unerfuellbaren Bereich mit 416.
2. Ganze Datei im Speicher. readFile() las jede Datei vollstaendig in den
RAM — bei einem Hero-Video bis MAX_UPLOAD_VIDEO_BYTES pro
gleichzeitigem Zugriff. Ersetzt durch einen Stream von der Platte,
inklusive Content-Length (vorher chunked, ohne Groessenangabe).
3. Keine bedingten Anfragen. Ohne ETag lud der Browser bei jedem Reload
den vollen Bildinhalt erneut. ETag aus Groesse + Aenderungszeit, 304
auf If-None-Match.
4. Bilder wurden in Originalaufloesung gespeichert. Ein 24-MP-Foto lag
mit 6000x4000 und 9 MB auf dem Volume, und next/image musste dieses
Bild fuer JEDE ausgelieferte Breite komplett neu dekodieren.
reencodeImage() begrenzt jetzt auf MAX_IMAGE_DIMENSION (2560px lange
Kante, Seitenverhaeltnis erhalten, kleinere Bilder werden nie
hochskaliert).
Zusaetzlich MAX_UPLOAD_BYTES von 8 auf 25 MB angehoben: 8 MB lagen unter
dem, was aktuelle Handykameras routinemaessig erzeugen — ein normales
Foto brach mit "Die Datei ist zu gross" ab, obwohl es serverseitig
ohnehin verkleinert wird. Gegen eine Dekompressionsbombe (kleine Datei,
die sich zu Milliarden Pixeln entpackt) bekommt sharp mit
MAX_INPUT_PIXELS eine ausdrueckliche Obergrenze von 100 MP, die die
Byte-Grenze allein nicht abdeckt.
Gemessen an einem 10,17-MB-Foto mit 6000x4000: vorher mit 413 abgelehnt,
jetzt als 2560x1707 / 1,88 MB gespeichert; next/image kalt fuer 640px von
180 ms auf 65 ms.
Der Kommentar zur proxy-body-size in k8s/06-ingress.yaml nennt jetzt das
neue Bild-Limit; die Annotation selbst (110m) deckt es unveraendert ab.
40 MB war fuer ein reales, nicht web-optimiertes Hero-Video (57 MB) zu
knapp. Ingress-Body-Size-Limit entsprechend mitgezogen.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Uploads (Bilder + Hero-Video) schlugen live fehl, lokal aber nicht: der
Container laeuft als non-root "nextjs", /app/uploads existierte nirgends
vorbereitet und gehoert root -> mkdir() scheiterte mit EACCES, unbehandelt
als HTML-500 statt JSON, der Client zeigte nur einen haengenden
"wird hochgeladen"-Zustand ohne Fehlermeldung.
- Dockerfile legt /app/uploads jetzt vor dem User-Wechsel an und
uebereignet es dem nextjs-Nutzer
- docker-compose.yml persistiert Uploads jetzt ueber ein eigenes Volume
(vorher gingen sie bei jedem Redeploy verloren) und setzt UPLOAD_DIR
explizit
- Beide Upload-Routen fangen Dateisystemfehler jetzt ab und liefern eine
echte JSON-Fehlermeldung statt eine unbehandelte Exception
- k8s-Manifeste vorsorglich mitgefixt (fsGroup fuer den Volume-Mount,
Ingress-Body-Size-Limit) fuer den Fall eines spaeteren
Kubernetes-Wechsels
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Dockerfile (Multi-Stage, "output: standalone"), docker-compose.yml mit
Caddy als einzigem nach aussen offenem Reverse-Proxy (verhindert
X-Forwarded-For-Faelschung fuer das App-eigene Rate-Limiting), Gitea
Actions Workflow der bei jedem Push zwei Image-Tags in die Gitea-
Container-Registry baut (schlankes Laufzeit-Image + ein Migrations-
Image mit Prisma-CLI), sowie rohe Kubernetes-Manifeste (Namespace,
ConfigMap, Secret-Vorlage, Postgres-/MySQL-StatefulSet, Migrations-Job,
App-Deployment, Ingress) fuer den Cluster-Betrieb. Siehe k8s/README.md
fuer den vollstaendigen Einrichtungs-/Deployment-Ablauf.
