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
63 lines
3.4 KiB
Markdown
63 lines
3.4 KiB
Markdown
# 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`:
|
||
setzt `Access-Control-Allow-Origin` NUR für den exakt konfigurierten
|
||
Origin (kein Wildcard), beantwortet `OPTIONS`-Preflights direkt mit
|
||
204, bevor der Request den `mux` erreicht.
|
||
- `archive/cmd/retention-api/main.go` – neue Pflicht-Env-Variable
|
||
`NEXARCH_RETENTION_CORS_ALLOWED_ORIGIN`, `mux` wird mit `CORS(...)`
|
||
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-api` neu gebaut, `/etc/nexarch/archive-retention-api.env`
|
||
um `NEXARCH_RETENTION_CORS_ALLOWED_ORIGIN=http://127.0.0.1:3099`
|
||
ergä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_admin` gegen
|
||
`/retention-classes`), liefert jetzt 200 mit korrektem
|
||
`Access-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.
|