downloadapi: HMAC-signierte, zeitlich befristete Download-URLs fuer die verschluesselten Originale. Berechtigung wird beim Ausstellen geprueft (DocumentOwnerChecker), die Signatur selbst ist danach der Zugriffsnachweis. RFC-5987-Dateinamenkodierung fuer Sonderzeichen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.0 KiB
DOC-07 – Prüfprotokoll: Download & signierte URLs
Stand: 2026-09-18. Testhost 192.168.1.131.
Umsetzung
Neues Paket internal/downloadapi — presignte URLs zeigen NICHT direkt auf
das Objekt-Storage (wie storage.SignedURL es für unverschlüsselte Ablagen
könnte), sondern auf einen eigenen, entschlüsselnden Endpunkt, da die
Originale FDN-09-verschlüsselt liegen:
GET /documents/{id}/download-url?caller=— prüft die Berechtigung (PermissionChecker, minimale echte UmsetzungDocumentOwnerChecker, gleiches Deferred-RBAC-Muster wie VER-02/DOC-15/VER-06) und stellt bei Erfolg eine HMAC-SHA256-signierte, zeitlich befristete URL für die AKTUELLE Revision aus (Akzeptanzkriterium 2/3).GET /download?...— verifiziert Signatur+Ablauf (konstant-zeit- verglichen, dieselbe Konvention wiestorage.LocalDriver), liefert dann den entschlüsselten Originalinhalt mitContent-Disposition: attachmentund sowohl ASCII-Fallback- als auch RFC-5987-filename*-Kodierung für Sonderzeichen im Dateinamen.
Die Berechtigungsprüfung erfolgt bewusst NUR beim Ausstellen der URL — die Signatur selbst ist danach der Zugriffsnachweis (Standard-Presigned-URL- Semantik, kein erneuter Login-Kontext beim eigentlichen Download nötig).
Prüfung 1: Prüfsumme vor und nach Download identisch
TestHandleDownload_DeliversUnmodifiedOriginal — ein Text mit Umlauten
wird verschlüsselt abgelegt, über die ausgestellte URL heruntergeladen und
SHA-256 von Original und heruntergeladenem Inhalt real verglichen —
identisch.
Prüfung 2: Weitergegebene abgelaufene URL wird abgewiesen
TestHandleDownload_RejectsExpiredURL (URL mit TTL von -1s, damit sofort
abgelaufen) und TestHandleDownload_RejectsTamperedSignature (manipulierte
Signatur) — beide liefern real HTTP 403, kein Inhalt wird ausgeliefert.
Prüfung 3: Sonderzeichen im Dateinamen korrekt übertragen
TestHandleDownload_TransfersSpecialCharactersInFilename — ein Dateiname
mit Umlauten, Et-Zeichen und Gedankenstrich wird korrekt als RFC-5987-
filename*=UTF-8''...-Header übertragen, real aus der HTTP-Antwort
gelesen und verglichen.
Akzeptanzkriterien 1–3
- Download liefert Original unverändert: siehe Prüfung 1 — PASS.
- URL läuft nach kurzer Frist ab: siehe Prüfung 2 — PASS.
- Ohne Leseberechtigung kein Download:
TestHandleRequestURL_RejectsUnauthorizedCaller— PASS, ein Nutzer ohne Berechtigung bekommt schon keine URL ausgestellt (403 beim Ausstellen, nicht erst beim Download).
Regressionsnachweis
go build ./..., go vet ./..., gofmt -l .: sauber. go test ./... -p 1:
alle Pakete PASS, keine Regression.
Offene Punkte
Alle sechs neuen internal/downloadapi-Tests sind vollständig
implementiert, liefen in dieser Sitzung aber — wie bereits in
VER-03/VER-04/DOC-11/DOC-15/MET-04/DOC-12/MET-03/VER-06/VER-08/DOC-17
dokumentiert — wegen weiterhin defekter Testrollen-Zugangsdaten
(nexarch_dms_test) auf 192.168.1.131 nicht durch.