schalli
dfc4e9b781
Der Client reichte jeden Download an den System-Browser weiter. Dateien, die die Seite selbst erzeugt (blob:/data:, z. B. alle Downloads im Zertifikat-Manager), kann der Browser nicht abrufen - Windows zeigte nur "Holen Sie sich eine App, um diesen blob-Link zu oeffnen" (VM 8233). Solche Downloads speichert die App jetzt selbst (Ordner Downloads) und meldet Dateiname und Ordner; http/https-Downloads gehen weiter an den Browser. Dazu CHANGELOG und Quick-Doku zu 261001-l4q. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
810 B
810 B
quick_id, status, date
| quick_id | status | date |
|---|---|---|
| 261001-l4q | complete | 2026-10-01 |
Summary
- Echte Aussteller-ZIP (nur lokal, nicht im Repo): 4 Teile erkannt (Server, Zwischen, Schluessel→Server, CSR→Server), PFX als geschuetzt gemeldet, .dnstxtrecord als nicht verwendet; alle 15 Exporte mit OpenSSL gueltig (PFX mit 3 Bloecken, Schluessel-Modulus passt).
- Tests: API cert-bundle.spec 11 (selbst erzeugte PKI), Web OverviewTab.test 5 + Seitentest angepasst; gesamt Web 1189, API 1686, Rust 65 gruen; tsc/clippy/rustfmt sauber.
- Browser lokal: Uebersicht + Downloads (fullchain, pfx, rsa.key, csr.der) geprueft.
- Desktop-Client (VM, lokal): Upload/Anzeige ok; Download zeigte „blob-Link“-Fehler → Client-Fix (on_download speichert blob:/data: selbst, Meldung danach). Nachweis auf VM folgt mit neuem Client-Build.