schalli
55aa287296
Plan, Ausfuehrungsbericht, Verifikation (9/9 must_haves) und Aktenstand; lokaler Nachweis per Playwright/mailhog fuer Browser- und Desktop-Marker-Fall. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016g2npLxzH5gZpg8s2S6vKh
45 KiB
45 KiB
phase, plan, type, wave, depends_on, autonomous, requirements, files_modified, estimate, must_haves
| phase | plan | type | wave | depends_on | autonomous | requirements | files_modified | estimate | must_haves | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| quick-260918-gza | 01 | execute | 1 | true |
|
|
|
|
Technischer Ansatz (nach Empfehlung des Orchestrators, keine Abweichung): Der bestehende Marker-/Cookie-Mechanismus aus quick-260917-h2s wird erweitert statt den WebView-User-Agent zu ueberschreiben. Der Rust-Client haengt neben desktop=1 die Parameter dv (CARGO_PKG_VERSION), dc (APP_COMMIT, darf leer sein) und dos (std::env::consts::OS) an; die Middleware legt daraus ein zweites, bereinigtes Cookie tessera_desktop_client an; der Web-Client liest es und schickt vier neue Multipart-Felder; die API leitet Kuerzel und Herkunftszeile in einem reinen, eigens getesteten Helfer ab. Alles rein informativ, nichts wird gespeichert.
Purpose: Der Betreiber erkennt am Betreff sofort, ob eine Meldung aus einem Client (und welchem Betriebssystem, welcher App-Version) oder aus einem Browser kommt — und kann das Postfach danach sortieren.
Output: Neue Datei origin.ts + Spec in der API; erweiterte DTO/Service/Specs; Rust-Marker mit Zusatzparametern; Middleware-Cookie; Web-Helfer + Nutzlastfelder; CHANGELOG und Handbuecher.
<execution_context>
@/.claude/gsd-core/workflows/execute-plan.md
@/.claude/gsd-core/templates/summary.md
</execution_context>
Quelldateien (alle zur Planungszeit vollstaendig gelesen; Aenderungsumfang ist auf diese Pfade begrenzt): @apps/api/src/bug-reports/dto/bug-report.dto.ts @apps/api/src/bug-reports/bug-reports.service.ts @apps/api/src/bug-reports/bug-reports.service.spec.ts @apps/api/src/bug-reports/bug-reports.controller.spec.ts @apps/desktop/src-tauri/src/lib.rs @apps/web/src/middleware.ts @apps/web/src/middleware.test.ts @apps/web/src/lib/desktop-client.ts @apps/web/src/lib/desktop-client.test.ts @apps/web/src/lib/bug-report-api.ts @apps/web/src/components/bug-report/bug-report-dialog.tsx @apps/web/src/components/bug-report/bug-report-button.test.tsx
<planning_measurements> Zur Planungszeit gemessen — der Executor braucht das nicht neu herzuleiten:
- Cookie-Kodierung: Next.js 15.5 (
next/dist/compiled/@edge-runtime/cookies) serialisiert Cookie-Werte mitencodeURIComponent.res.cookies.set('tessera_desktop_client', '1.2.0|a6d1a64|windows', …)erzeugt den Headertessera_desktop_client=1.2.0%7Ca6d1a64%7Cwindows; Path=/; …. Im Browser steht deshalb indocument.cookiedie KODIERTE Form. Der Parser indesktop-client.tsmussdecodeURIComponent(in try/catch) anwenden, bevor er an|trennt.res.cookies.get(name)?.valuein Middleware-Tests liefert bereits den dekodierten Wert. - Globale ValidationPipe (
apps/api/src/main.tsZ. 17-20):whitelist: true, transform: true, KEINforbidNonWhitelisted. Folge: Ein neuer Web-Bau gegen eine alte API verliert die vier Felder still (kein 400); ein alter Web-Bau gegen die neue API liefertundefined— beide Deploy-Reihenfolgen sind sicher, solange alle vier DTO-Felder@IsOptional()tragen. - Baseline-Tests:
pnpm --filter @tessera/api exec vitest run src/bug-reports-> 11/11 gruen (8 Service + 3 Controller).pnpm --filter @tessera/web exec vitest run src/lib/desktop-client.test.ts src/middleware.test.ts-> 11/11 gruen (6 + 5).bug-report-button.test.tsxhat 11 Tests. Rust: 33 Tests laut STATE (kgc),cargo test --libim Verzeichnisapps/desktop/src-tauri(target/ existiert, inkrementell). - Biome: installiert (2.5.0), aber laut Ledger #35 (STATE.md, 260914-ebg) im Bestand nicht lauffaehig — KEIN Biome-Gate in diesem Plan. Formatierung von Hand am Bestand orientieren (2 Leerzeichen, einfache Anfuehrungszeichen, Zeilen bis 100).
- Skripte:
type-check=tsc --noEmitin beiden Apps (pnpm --filter @tessera/api type-check,pnpm --filter @tessera/web type-check). Paketnamen@tessera/api,@tessera/web. Kein Paketmanager-Install noetig (keine neue Abhaengigkeit;class-validator0.15 liefertIsIn). - Docs-Stellen:
docs/anleitung-administration.mdZ. 208 beschreibt den Mailinhalt und den Betreff[Tessera Fehlermeldung](dort gehoert die Herkunft hin).docs/anleitung-betrieb.mdhat KEINEN eigenen Fehlermeldungs-/SMTP-Abschnitt und erwaehntdesktop=1nirgends; die Anknuepfpunkte sind die Fehlersuche-Tabelle in Kapitel 7 (Zeile „Fehlermeldungen der Anwender kommen nicht an“, Z. 341) und die Tabelle „Fehlerbilder“ in Kapitel 10 (ab Z. 699).docs/mandantentrennung-zugriffsklassifikation.mdlistet keine Rumpffelder -> bleibt unveraendert. Kein UI-Text aendert sich ->de.json/en.jsonbleiben unveraendert. </planning_measurements>
1. `apps/api/src/bug-reports/origin.ts` (NEU, keine Abhaengigkeit ausser TypeScript): Kopfkommentar deutsch (ASCII-Umlaute wie im Bestand): Zweck (quick-260918-gza — Herkunft einer Fehlermeldung ausweisen, weil WebView2 wie Edge und WebKitGTK wie Safari aussehen), Trust-Modell (alle Eingaben stammen vom Client, rein informativ, laengenbegrenzt, nie fuer Routing/Berechtigung, T-GZA-01), warum Regex statt Bibliothek (kein neues Paket, fuenf Browser und fuenf Systeme reichen fuer ein Postfach). Exporte: Typ `ClientKind = 'desktop' | 'browser'`; Interface `OriginInput { clientKind?: string; clientOs?: string; clientVersion?: string; clientCommit?: string; userAgent?: string }`; Interface `Origin { tag: string; line: string }` — `tag` ist das Betreff-Kuerzel in eckigen Klammern, `line` der Text NACH dem Label `Herkunft: ` (der Dienst setzt das Label davor); Interface `ParsedUserAgent { browser: string; os: string }`; Konstante `UNKNOWN = 'unbekannt'`.
`parseUserAgent(ua: string): ParsedUserAgent` — Browser in dieser Reihenfolge pruefen (die erste Uebereinstimmung gewinnt): `Edg/(\d+)` -> `Edge N`; `OPR/(\d+)` -> `Opera N`; `Firefox/(\d+)` -> `Firefox N`; `(?:Chrome|CriOS)/(\d+)` -> `Chrome N`; `Safari/` OHNE `Chrome/` -> `Safari N` mit N aus `Version/(\d+)`, ohne `Version/` nur `Safari`; sonst `UNKNOWN`. Betriebssystem in dieser Reihenfolge: `Windows NT` -> `Windows`; `Android` -> `Android`; `iPhone|iPad|iPod` -> `iOS`; `Mac OS X|Macintosh` -> `macOS`; `Linux|X11` -> `Linux`; sonst `UNKNOWN`. Kommentar an der Reihenfolge: Android-UAs enthalten `Linux`, iPad-UAs enthalten `like Mac OS X`, Edge/Opera-UAs enthalten `Chrome/` und `Safari/` — deshalb die Reihenfolge.
`describeOrigin(input: OriginInput): Origin` — Hilfsfunktion `clean(value, max = 40)`: `String(value ?? '')`, alles ausser `[A-Za-z0-9.+_-]` entfernen, `slice(0, max)` (T-GZA-01: kein Zeilenumbruch, kein Markup in der Mail). Wenn `input.clientKind === 'desktop'`: `osLabel` aus `clean(clientOs).toLowerCase()` ueber die Abbildung `windows -> Windows`, `linux -> Linux`, `macos -> macOS`, sonst `UNKNOWN`; `version = clean(clientVersion)`, `commit = clean(clientCommit)`; `appLabel` = `Tessera-App ${version} · Stand ${commit}` wenn beide nicht leer, `Tessera-App ${version}` wenn nur Version, sonst leer (gleiche Regel wie `client_info_label` in lib.rs); `line = Desktop-App (${osLabel})` plus `, ${appLabel}` falls appLabel nicht leer; `tag` = `[Desktop/${osLabel}]` wenn osLabel nicht UNKNOWN, sonst `[Desktop]`. Sonst (alles andere, auch `undefined`): `{ browser, os } = parseUserAgent(input.userAgent ?? '')`, `line = Browser — ${browser} auf ${os}` (Gedankenstrich U+2014 wie im Auftrag), `tag = '[Browser]'`.
2. `apps/api/src/bug-reports/dto/bug-report.dto.ts`: `IsIn` aus `class-validator` importieren. Vier neue optionale Felder ans Ende der Klasse, jeweils mit Doc-Kommentar: `clientKind?: 'desktop' | 'browser'` mit `@IsOptional() @IsIn(['desktop', 'browser'])`; `clientOs?: string` mit `@IsOptional() @IsString() @MaxLength(20)`; `clientVersion?: string` mit `@IsOptional() @IsString() @MaxLength(40)`; `clientCommit?: string` mit `@IsOptional() @IsString() @MaxLength(40)`. Kopfkommentar der Klasse um einen Absatz ergaenzen: die vier Felder kommen seit quick-260918-gza vom Web-Client (Browser: `clientKind=browser`, uebrige leer; Desktop-App: aus dem Cookie `tessera_desktop_client`); sie sind optional, damit aeltere Web-Baue weiter gueltig senden (Rueckfall `browser` im Dienst); `whitelist: true` verlangt die Deklaration hier, sonst wuerde die Pipe sie entfernen; rein informativ, laengenbegrenzt (T-GZA-01).
3. `apps/api/src/bug-reports/bug-reports.service.ts`: `describeOrigin` aus `./origin` importieren. Vor Schritt (5) `const origin = describeOrigin(dto);`. Betreff wird `[Tessera Fehlermeldung] ${origin.tag} ${dto.webVersion} ${dto.webChannel} - ${pageShort}`. Im Text-Array direkt VOR der Zeile `Browser: ${dto.userAgent}` die neue Zeile `Herkunft: ${origin.line}` einfuegen; `Browser:` und `Fenster:` bleiben unveraendert. Protokollzeile (9) wird `Bug report ${origin.tag} from ${user.username} …` (Rest unveraendert; das Kuerzel ist ein aufgezaehlter Wert aus origin.ts, nie ein roher Client-String — deshalb protokollierbar). Kopfkommentar der Datei um einen Absatz „Herkunft (quick-260918-gza)“ ergaenzen: warum Kuerzel im Betreff (Sortieren im Postfach), warum der rohe User-Agent bleibt, Verweis auf origin.ts und T-GZA-01.
4. Specs gemaess `<behavior>` anpassen bzw. anlegen; Kopfkommentar von `origin.spec.ts` im Stil der bestehenden Specs (deutsch, Zweck, Liste der Faelle). In `bug-reports.service.spec.ts` und `bug-reports.controller.spec.ts` den Kopfkommentar um einen Satz zu den neuen Tests ergaenzen (Anzahl korrigieren).
Commit nach gruenem Lauf: `feat(bug-reports): Herkunft der Fehlermeldung im Betreff-Kuerzel und als Zeile Herkunft ausweisen`.
1. `apps/desktop/src-tauri/src/lib.rs`: Neue reine Funktion `fn with_client_marker(url: &tauri::Url, version: &str, commit: &str, os: &str) -> tauri::Url` — klont die URL, haengt per `query_pairs_mut().append_pair` nacheinander `("desktop", "1")`, `("dv", version)`, `("dc", commit.trim())`, `("dos", os)` an (Reihenfolge fest, `dc` auch leer anhaengen). Die bestehende `fn with_desktop_marker(url: &tauri::Url) -> tauri::Url` wird zur Huelle: `with_client_marker(url, env!("CARGO_PKG_VERSION"), env!("APP_COMMIT"), std::env::consts::OS)` — so bleiben die drei Aufrufstellen (`save_server_url`, `open_server`, `setup`) UNVERAENDERT und die Tests bleiben rein (kein `env!` in der Erwartung). Doc-Kommentar von `with_desktop_marker` erweitern: seit quick-260918-gza wandern Version, Commit-Stempel und Betriebssystem (`dv`, `dc`, `dos`) mit, die Middleware legt daraus das Cookie `tessera_desktop_client` an, aus dem der Fehler-melden-Knopf die Herkunft der Meldung fuellt; `desktop=1` bleibt unveraendert, damit ein neuer Client gegen eine aeltere Middleware weiter erkannt wird; die Werte gehen NUR in die Navigation, nie in den Store (wie bisher); der Browser-Rueckfall `open_download_page` bekommt weiterhin keinen Marker. `mod tests`: die drei bestehenden `with_desktop_marker_*`-Tests auf `with_client_marker(&url, "1.2.0", "a6d1a64", "windows")` umstellen (Erwartungen laut `<behavior>`), Test fuer leeren Commit (`""` und `" "` -> `dc=`) und einen Test fuer die Huelle ueber `query_pairs()` ergaenzen. `cargo fmt` anwenden (2-Zeilen-Doc-Umbrueche wie im Bestand).
2. `apps/web/src/middleware.ts`: Konstante `DESKTOP_CLIENT_COOKIE = 'tessera_desktop_client'` und drei Muster als Modulkonstanten: `DESKTOP_VERSION_RE = /^[A-Za-z0-9][A-Za-z0-9.+_-]{0,39}$/`, `DESKTOP_COMMIT_RE = /^[A-Za-z0-9]{0,40}$/` (leer erlaubt), `DESKTOP_OS_RE = /^[a-z]{1,20}$/`. Neue reine Hilfsfunktion `buildDesktopClientCookieValue(params: URLSearchParams): string | null` — liest `dv`, `dc`, `dos`; wenn eines `null` (fehlt) ist oder sein Muster nicht passt -> `null`; sonst `${dv}|${dc}|${dos}` (hoechstens 82 Zeichen durch die Muster). In `withDesktopCookie` innerhalb des bestehenden `if (desktop === '1')`-Zweigs: `tessera_desktop=1` wie bisher setzen; zusaetzlich `const info = buildDesktopClientCookieValue(req.nextUrl.searchParams); if (info !== null) res.cookies.set(DESKTOP_CLIENT_COOKIE, info, { …dieselben Optionen wie fuer tessera_desktop… })`. Ohne gueltige Parameter wird das Info-Cookie NICHT gesetzt und NICHT geloescht (alter Client -> die Mail sagt `Desktop-App (unbekannt)`). Doc-Kommentar von `withDesktopCookie` ergaenzen: zweites Cookie, Herkunft (quick-260918-gza), Bereinigung per Muster und Laenge, warum `httpOnly: false` (wird von `getDesktopClientInfo()` gelesen; Version/OS sind kein Geheimnis, dieselbe Vertrauensstufe wie der User-Agent), Hinweis dass Next den Wert mit `encodeURIComponent` serialisiert (T-GZA-03). Tests laut `<behavior>` in `middleware.test.ts` ergaenzen; Kopfkommentar um einen Satz erweitern.
3. `apps/web/src/lib/desktop-client.ts`: `export const DESKTOP_CLIENT_COOKIE_NAME = 'tessera_desktop_client'`; `export interface DesktopClientInfo { version: string; commit: string; os: string }`; `export function parseDesktopClientCookie(cookieString: string): DesktopClientInfo | null` — trennt an `;`, trimmt, sucht den Eintrag mit Praefix `${DESKTOP_CLIENT_COOKIE_NAME}=`, nimmt den Rest, dekodiert per `decodeURIComponent` in try/catch (bei Fehler den Rohwert nehmen), trennt an `|`; genau drei Teile, Teil 1 (version) und Teil 3 (os) nicht leer, sonst `null`; Rueckgabe `{ version, commit, os }`. `export function getDesktopClientInfo(): DesktopClientInfo | null` — `typeof document === 'undefined'` -> `null`, sonst `parseDesktopClientCookie(document.cookie)`. Kopfkommentar ergaenzen (Gegenstueck zu `buildDesktopClientCookieValue`, warum dekodieren — Next kodiert `|` als `%7C`, gemessen). Tests laut `<behavior>`; `clearCookie()` im Test loescht beide Cookies.
4. `apps/web/src/lib/bug-report-api.ts`: `BugReportPayload` um `clientKind: 'desktop' | 'browser'`, `clientOs: string`, `clientVersion: string`, `clientCommit: string` erweitern; in `sendBugReport` nach `clientTime` vier `body.append(...)`-Zeilen fuer genau diese Feldnamen (Leerstrings mitschicken — das DTO ist optional, aber die Felder sollen fuer den Browser-Fall sichtbar leer sein, nicht fehlen). Kopfkommentar um einen Satz ergaenzen (Herkunft, quick-260918-gza; Desktop-Werte kommen aus `getDesktopClientInfo()`). NEU `apps/web/src/lib/bug-report-api.test.ts` laut `<behavior>` (Kopfkommentar: warum diese Datei erst jetzt entsteht — bisher pruefte nur der Komponententest die FormData; die reinen Nutzlastfelder gehoeren an die Funktion selbst).
5. `apps/web/src/components/bug-report/bug-report-dialog.tsx`: `getDesktopClientInfo` und `isDesktopClient` aus `@/lib/desktop-client` importieren. In `handleSend` vor dem `sendBugReport`-Aufruf: `const desktop = isDesktopClient(); const info = desktop ? getDesktopClientInfo() : null;` und im Aufruf `clientKind: desktop ? 'desktop' : 'browser', clientOs: info?.os ?? '', clientVersion: info?.version ?? '', clientCommit: info?.commit ?? ''`. Kein UI-Text, keine Uebersetzung aendert sich. Kurzer Kommentar an der Stelle: Herkunft (quick-260918-gza) — `tessera_desktop` entscheidet Desktop/Browser, `tessera_desktop_client` liefert die Details; fehlt es (alter Client), bleibt es bei Desktop ohne Details. `bug-report-button.test.tsx` laut `<behavior>` erweitern (Test 2 ergaenzen, Tests 12 und 13 neu, Cookie-Aufraeumen im `afterEach`, Kopfkommentar „Elf Tests“ -> „Dreizehn Tests“).
Zwei Commits nach gruenem Lauf: `feat(desktop): Version, Stand und Betriebssystem im Desktop-Marker mitgeben (dv, dc, dos)` fuer lib.rs; `feat(web): Herkunft der Fehlermeldung — Cookie tessera_desktop_client und Client-Felder in der Nutzlast` fuer die Web-Dateien.
1. `CHANGELOG.md`, Abschnitt `## Unveröffentlicht` -> `### Geändert`, neue Zeile am Ende der Liste: `- Fehler melden: Fehlermeldungen nennen jetzt die Herkunft – Browser oder Desktop-App, Betriebssystem, bei der Desktop-App auch Version und Stand; der Betreff trägt dafür ein Kürzel wie „[Browser]“, „[Desktop/Windows]“ oder „[Desktop/Linux]“, nach dem sich das Postfach sortieren lässt`.
2. `docs/anleitung-administration.md`, Absatz **Fehlermeldungen an** (Z. 208): den Teilsatz „— der Betreff beginnt mit „[Tessera Fehlermeldung]“, das Bild hängt als PNG an.“ ersetzen durch einen Teilsatz, der sagt: der Betreff beginnt mit „[Tessera Fehlermeldung]“ und einem Kürzel für die Herkunft („[Browser]“, „[Desktop/Windows]“ oder „[Desktop/Linux]“), nach dem Sie das Postfach sortieren oder filtern können; im Text nennt die Zeile „Herkunft“ bei Browsern Browser und Betriebssystem (Beispiel „Browser — Chrome 129 auf Windows“), bei der Desktop-App Betriebssystem, Version und Stand (Beispiel „Desktop-App (Windows), Tessera-App 1.2.0 · Stand a6d1a64“); das Bild hängt als PNG an. Der uebrige Absatz bleibt.
3. `docs/anleitung-betrieb.md`:
a) Kapitel 7, Tabellenzeile „Fehlermeldungen der Anwender kommen nicht an“ (Z. 341), Spalte „Prüfen / Beheben“: die Klammer „(eine Zeile je gesendeter Meldung, `Bug report mail failed` bei Versandfehler)“ erweitern zu „(eine Zeile je gesendeter Meldung mit dem Herkunfts-Kürzel `[Browser]`, `[Desktop/Windows]` oder `[Desktop/Linux]`, `Bug report mail failed` bei Versandfehler)“.
b) Kapitel 10, Tabelle „Fehlerbilder“ (ab Z. 699), neue letzte Zeile: Symptom „Eine Fehlermeldung aus der Desktop-App nennt als Herkunft „Desktop-App (unbekannt)“ ohne Version, Betreff-Kürzel `[Desktop]`“ — Ursache „Der Client ist älter als diese Fassung: er meldet dem Server beim Start nur `desktop=1`, nicht Version, Stand und Betriebssystem (Parameter `dv`, `dc`, `dos`, aus denen `web` das Cookie `tessera_desktop_client` bildet)“ — Prüfen/Beheben „Kein Fehler, die Meldung ist trotzdem als Desktop-App erkennbar. Client über „Auf Version … aktualisieren“ im Infobereich oder den Browser-Installer aktualisieren; danach stehen Betriebssystem, Version und Stand in der Meldung.“
Nicht anfassen: `docs/mandantentrennung-zugriffsklassifikation.md` (listet keine Rumpffelder), `docs/anleitung-anwender.md` (Anwender sehen keine Aenderung), `de.json`/`en.json` (kein UI-Text).
Commit: `docs: Fehlermeldungen — Herkunft (Browser/Desktop-App, Betriebssystem, Version) und Betreff-Kürzel (Handbücher, CHANGELOG)`.
<threat_model>
Trust Boundaries
| Boundary | Description |
|---|---|
Desktop-Client -> Web (Query desktop=1&dv&dc&dos) |
Ungepruefte Query-Parameter einer Navigation; jeder Browser kann sie ebenso setzen |
Web-Middleware -> Browser (Cookie tessera_desktop_client) |
Nicht-httpOnly-Cookie, fuer Seiten-JavaScript lesbar und vom Anwender aenderbar |
Browser -> API (POST /bug-reports, vier neue Multipart-Felder) |
Vom Client gelieferte Strings, unbeglaubigt wie der User-Agent |
| API -> Postfach des Betreibers (Betreff, Textzeile, Protokollzeile) | Client-Text landet in einer E-Mail und teilweise im Log |
STRIDE Threat Register (ASVS Level 1)
| Threat ID | Category | Component | Severity | Disposition | Mitigation Plan |
|---|---|---|---|---|---|
| T-GZA-01 | Spoofing / Tampering | clientKind, clientOs, clientVersion, clientCommit im DTO; describeOrigin |
low | mitigate | Rein informativ: nie fuer Routing, Berechtigung oder Speicherung genutzt; @IsIn(['desktop','browser']), @MaxLength 20/40/40; clean() in origin.ts laesst nur [A-Za-z0-9.+_-] und 40 Zeichen zu (kein Zeilenumbruch, kein Markup in der Mail); OS wird auf drei feste Labels abgebildet; ins Log geht NUR das aufgezaehlte Kuerzel, nie ein Rohwert (Test 9 im Service-Spec, Test 10 in origin.spec) |
| T-GZA-02 | Tampering | Betreff-Zeile (Header-Injection) | low | mitigate | In den Betreff geht ausschliesslich origin.tag — ein Wert aus einer festen Menge ([Browser], [Desktop], `[Desktop/Windows |
| T-GZA-03 | Tampering | withDesktopCookie — Query -> Cookie tessera_desktop_client |
low | mitigate | Drei feste Muster (DESKTOP_VERSION_RE, DESKTOP_COMMIT_RE, DESKTOP_OS_RE), Gesamtlaenge ≤ 82; nur gesetzt, wenn desktop=1 UND alle drei Parameter vorhanden und gueltig; Middleware trifft keine Entscheidung auf Grund des Werts; sameSite: 'lax', secure bei https wie das bestehende Cookie (Tests 6-9 in middleware.test.ts) |
| T-GZA-04 | Information Disclosure | Cookie tessera_desktop_client (App-Version und OS fuer Seiten-JS lesbar) |
low | accept | Dieselbe Vertrauensstufe und Sichtbarkeit wie der User-Agent, den jede Seite ohnehin liest; kein Geheimnis, kein Token; nur die eigene Web-App laeuft im WebView |
| T-M97-03 | Denial of Service | main.ts, Body-Limits |
medium | mitigate (unveraendert) | Kein globales Limit angefasst; vier kurze Textfelder innerhalb des bestehenden Multipart-Rumpfs, DTO-Grenzen wie oben |
| T-M97-09 | Spoofing | Irrefuehrende Herkunftsangaben durch einen Anwender | low | accept | Wie bisher fuer Beschreibung/Fehlerliste: reiner Text an den Administrator des eigenen Mandanten; Benutzer/Mandant/API-Version kommen weiterhin aus Sitzung und Umgebung, nicht aus dem Rumpf |
| T-GZA-SC | Tampering | Paketinstallationen | — | n/a | Keine neue npm-/cargo-Abhaengigkeit (Regex und Standardbibliothek); kein Install-Schritt in diesem Plan |
| </threat_model> |
Kein Biome-Gate (Ledger #35: Konfiguration im Bestand nicht lauffaehig).
Nachweis durch den Orchestrator NACH der Ausfuehrung (nicht Aufgabe des Executors):
- Browser-Fall lokal mit Playwright MCP und mailhog (
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d mailhog,docker compose up -d --build api web): Fehler melden -> Mail inhttp://localhost:8025mit Betreff[Tessera Fehlermeldung] [Browser] dev dev - /…und ZeileHerkunft: Browser — Chrome <N> auf Linux; ZeilenBrowser:/Fenster:weiterhin vorhanden;docker compose logs api | grep "Bug report"zeigt das Kuerzel. - Desktop-Fall nach CI-Bau auf der Windows-Test-VM (Zugang laut Memory
reference_windows_test_vm.md): Client installieren bzw. per In-App-Update aktualisieren, gegen alpha melden -> Betreff[Desktop/Windows], ZeileHerkunft: Desktop-App (Windows), Tessera-App <Version> · Stand <sha7>; Kontrolle des Cookiestessera_desktop_clientin der Seite ueber Einstellungen -> Desktop-App ist nicht noetig, die Mail genuegt. - Alter Client (optional): ein bestehender 1.2.0-Client ohne Update erzeugt
[Desktop]undDesktop-App (unbekannt)— das ist das dokumentierte Verhalten (Betriebshandbuch Kap. 10).
<success_criteria>
- Jede Fehlermeldungs-Mail traegt im Betreff direkt nach
[Tessera Fehlermeldung]genau eines der Kuerzel[Browser],[Desktop/Windows],[Desktop/Linux](oder[Desktop]bei einem alten Client) und im Text die ZeileHerkunft: …in der im Auftrag festgelegten Form;Browser:undFenster:bleiben. - Desktop-Client, Middleware, Web-Helfer, Nutzlast, DTO und Dienst sind durchgaengig verbunden und je Schicht durch Tests belegt (Rust 5 Marker-Tests, Middleware 9, desktop-client ≥ 11, bug-report-api 3, Komponententest 13, origin ≥ 8, Service 10, Controller 4).
- Rueckwaertskompatibel in beide Richtungen (alter Client, alter Web-Bau, alte API) — kein 400, kein Verlust der bisherigen Meldung.
- Keine neue Abhaengigkeit, keine DB-Aenderung,
main.tsunveraendert, kein UI-Text geaendert. - CHANGELOG und beide Handbuecher beschreiben Kuerzel und Herkunftszeile; drei bis vier Code-/Doku-Commits mit den vorgegebenen Praefixen;
.planning/-Artefakte werden vom Executor NICHT committet. </success_criteria>