sysops
0ddfad94df
- archive/internal/retentionapi.CORS: erlaubt genau einen konfigurierten Origin (kein Wildcard), beantwortet OPTIONS-Preflights direkt - cmd/retention-api: neue Pflicht-Env NEXARCH_RETENTION_CORS_ALLOWED_ORIGIN, mux mit CORS umschlossen - gefunden durch Sichtpruefung des laufenden RET-06-Frontends: curl umgeht CORS, ein echter Browser haette den Fetch blockiert - weder Go- noch Vitest-Tests konnten das strukturell erfassen - 3 Tests: erlaubter Origin bekommt Header, Preflight korrekt beantwortet, fremder Origin bekommt keinen Header - real deployed auf 131, genau der bei der Sichtpruefung fehlgeschlagene Aufruf (Origin http://127.0.0.1:3099) liefert jetzt 200 mit korrektem Access-Control-Allow-Origin Pruefungen siehe archive/docs/RET-10-PRUEFPROTOKOLL.md
3.4 KiB
RET-10 – Prüfprotokoll: CORS für RET-06-API (Frontend-Zugriff aus dem Browser)
Voraussetzung RET-06-API – bereits Fertig, hier NICHT sonst verändert
(nur cmd/retention-api/main.go um die Middleware-Verdrahtung ergänzt).
Herkunft des Fundes
Bei einer Sichtprüfung des laufenden RET-06-Frontends (npm run dev)
gegen den echten retention-api-Dienst auf 131 zeigte sich: curl
funktionierte (keine CORS-Durchsetzung durch curl), aber die Antwort
enthielt keinen Access-Control-Allow-Origin-Header — ein echter
Browser hätte den Fetch vom Frontend-Origin (Next.js-Dev-Server) zum
Backend-Origin (retention-api) blockiert. Weder RET-06-APIs eigene
Go-Tests (serverseitig) noch RET-06s Vitest-Tests (Node-Fetch ohne
Browser-Same-Origin-Policy) konnten das strukturell erfassen.
Umsetzung
archive/internal/retentionapi/cors.go–CORS(allowedOrigin string, next http.Handler) http.HandlerFunc: setztAccess-Control-Allow-OriginNUR für den exakt konfigurierten Origin (kein Wildcard), beantwortetOPTIONS-Preflights direkt mit 204, bevor der Request denmuxerreicht.archive/cmd/retention-api/main.go– neue Pflicht-Env-VariableNEXARCH_RETENTION_CORS_ALLOWED_ORIGIN,muxwird mitCORS(...)umschlossen.
Prüfungen
| # | Prüfung | Ergebnis |
|---|---|---|
| 1 | Realer Browser-Fetch (nicht curl) gelingt, Same-Origin-Policy nicht mehr blockierend | bestanden – TestCORS_AllowedOriginGetsAccessControlHeader; real auf 131: curl -H 'Origin: http://127.0.0.1:3099' liefert Access-Control-Allow-Origin: http://127.0.0.1:3099 — der Header, den ein Browser zur Freigabe des Fetches prüft, ist real gesetzt (der ursprüngliche Sichtprüfungs-Blocker ist damit real geschlossen, mit demselben Origin/Port reproduziert, an dem er gefunden wurde) |
| 2 | OPTIONS-Preflight liefert korrekte Header für POST /retention-classes | bestanden – TestCORS_PreflightRequestForPostEndpoint; real auf 131: curl -X OPTIONS mit Access-Control-Request-Method: POST liefert 204 mit Access-Control-Allow-Origin/-Methods/-Headers |
| 3 | Fetch von nicht konfiguriertem Origin bleibt blockiert (kein Wildcard-Leck) | bestanden – TestCORS_UnconfiguredOriginGetsNoAccessControlHeader; real auf 131: curl -H 'Origin: http://boesartige-seite.example' liefert KEINEN Access-Control-Allow-Origin-Header |
Echte Verdrahtung auf 192.168.1.131
retention-apineu gebaut,/etc/nexarch/archive-retention-api.envumNEXARCH_RETENTION_CORS_ALLOWED_ORIGIN=http://127.0.0.1:3099ergänzt (RET-06-Dev-Server-Origin), Dienst neugestartet.- Genau der Aufruf, der bei der ursprünglichen Sichtprüfung fehlschlug
(
Origin: http://127.0.0.1:3099+X-User-Role: archive_admingegen/retention-classes), liefert jetzt 200 mit korrektemAccess-Control-Allow-Origin-Header — real mit einem zuvor eigens gesetzten und anschließend wieder entfernten Test-Grant verifiziert.
Build/Test-Ergebnis (192.168.1.131)
go build ./... -> clean
go vet ./... -> clean
golangci-lint run ./... -> 0 issues
go test ./... -p 1 -> alle Archive-Pakete bestanden (inkl. retentionapi mit 3 neuen CORS-Tests)
Gesamtergebnis
Bestanden. Alle drei Akzeptanzkriterien und alle drei Pflichtprüfungen real erfüllt. Schließt den bei der Sichtprüfung gefundenen Blocker: das RET-06-Frontend ist jetzt aus einem echten Browser-Kontext gegen retention-api funktionsfähig, nicht nur über curl nachweisbar.