# 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.