Skip to content

feat(drive): Zwischenspeicher im Heimnetz und „Offline verfügbar“ - #187

Merged
CallMeTechie merged 2 commits into
mainfrom
feat/home-cache
Nov 5, 2026
Merged

CallMeTechie merged 2 commits into
mainfrom
feat/home-cache

Conversation

@CallMeTechie

Copy link
Copy Markdown
Owner

Phase 3b, Teil D (Android): Die App nutzt den Zwischenspeicher im Heimnetz (GateControl ≥ 1.231.0, Drive ≥ 1.20.0).

Was die App jetzt tut

  • Drive-Downloads (GET nodes/<id>/content – Öffnen/Senden von Dateien, Foto-Originale, Tresor-Dateien) schicken X-GC-Local: a.b.c.d[,…] mit, wenn
    • Drive homeCache in GET me meldet,
    • das Gerät private IPv4-Adressen (RFC 1918) auf WLAN/Ethernet hat (nie VPN-Netz, nie Mobilfunk, VPN-Subnetz zusätzlich ausgefiltert),
    • und die vorhandene Heimnetz-Prüfung (GET /api/v1/client/home-network) „zu Hause“ sagt (Ergebnis je Adress-Satz 10 Min. gemerkt, keine Antwort 1 Min., Zeitlimit 4 s).
      Ältere Versionen (…/versions/<vid>/content) nie.
  • lan-Hinweis → Laden direkt vom Gateway (HomeCacheFetcher, core/network):
    • eigener X509TrustManager nur für diese Verbindung, nimmt ausschließlich das Zertifikat mit SHA-256(DER) = tlsSha256 an; HostnameVerifier prüft Adresse und Pin (kein { true }); zusätzlich Prüfung im Netzwerk-Interceptor vor dem Request
    • Hinweis nur gültig mit https://<private IPv4>/blob/<sha256>, 64-Hex-Hashes, exp mit 5 s Reserve; sha256 muss zum Knoten passen
    • kein Proxy, keine Redirects, keine Zugangsdaten/Interceptoren der App, Accept-Encoding: identity
    • Socket an das WLAN/Ethernet gebunden, dessen Subnetz die Gateway-Adresse enthält – also am Tunnel vorbei (die App ist VPN-Besitzerin und darf die Netze darunter nutzen, wie GateDrop direkt). Ohne solches Netz routet das System (ggf. durch den Tunnel – korrekt, nur nicht schneller).
    • Bytes in eine Temp-Datei, SHA-256 + Größe geprüft; erst dann bekommt der Aufrufer sie (Datei wird beim Schließen gelöscht). Jeder Fehler (Pin, TLS, Timeout, 403/404, Hash, Größe, exp) → still der normale Download.
    • Logs nur host:port/blob/<sha-Anfang> + Grund, nie URL-Query/Signatur; X-GC-Local im HTTP-Log geschwärzt.
  • „Offline verfügbar“ (Feature offline): Eintrag im ⋮-Menü von Dateien und Ordnern (Ordnerseiten, Drive-Tab, Suche), Haus-Markierung in Liste und Kacheln, Liste „Offline verfügbar“ (Symbol im Drive-Menü) mit Öffnen und Entfernen; Grenze 500 mit eigenem Text.
    Die App hat keinen eigenen Offline-Speicher (nur den 24-h-Cache geöffneter Dateien). „Offline verfügbar“ heißt daher hier „zu Hause im Zwischenspeicher bevorzugt bereithalten“ – so steht es im Menü und auf der Liste („Auf diesem Handy wird nichts dauerhaft gespeichert“; ohne homeCache: „vorgemerkt“).
  • App-Updates: Die App lädt Updates nicht selbst (Play-Build: Google Play; sonst öffnet sie downloadUrl im Browser, der kein Pinning kann). Der lan-Weg für Updates wird deshalb nicht genutzt.

Tests

  • HomeCacheTest (core/network, echter TLS-Server mit selbstsigniertem Zertifikat aus keytool): Pin passt / falsch / mit Doppelpunkten, falscher Hash, 403/404, Redirect, exp abgelaufen, fremder Hash, zu groß, niemand erreichbar, Fortschritt, TrustManager, Hinweis-Prüfung, Header nur private Adressen / ohne VPN-Netz / max. 4, Subnetz.
  • DriveHomeCacheTest, HomeSiteMemoryTest (app).
  • Lokal: alle Unit-Tests grün (2100), lintRelease ohne Befund in den geänderten Dateien.

Nicht gegen ein echtes Gateway getestet.

Version nicht erhöht (Release-Workflow).


Generated by Claude Code

Claude added 2 commits November 5, 2026 14:01
- Drive-Downloads (GET nodes/<id>/content, auch Foto-Originale und
  Tresor-Dateien) schicken zu Hause die LAN-IPv4-Adressen als X-GC-Local –
  nur private RFC-1918-Adressen der WLAN-/Ethernet-Netze, nie die des VPN,
  und nur, wenn die Heimnetz-Prüfung des Servers „zu Hause“ sagt (Antwort
  10 Min. gemerkt, Feature homeCache in GET me)
- Kommt ein lan-Hinweis zurück, lädt die App direkt vom Gateway:
  HomeCacheFetcher (core/network) mit eigenem TrustManager nur für diese
  Verbindung, der ausschließlich das Zertifikat mit tlsSha256 annimmt,
  Hostnamen-Prüfung an den Pin gebunden, kein Proxy, keine Weiterleitungen,
  keine Zugangsdaten der App; Socket an das WLAN gebunden, das die
  Gateway-Adresse enthält (am Tunnel vorbei). Danach sha256 und Größe
  geprüft; bei jedem Fehler (Pin, Timeout, 403/404, Hash, exp) still der
  normale Download. Logs ohne URL-Query/Signatur
- „Offline verfügbar“ (Feature offline): Eintrag im ⋮-Menü von Dateien und
  Ordnern (Ordner-, Such- und Drive-Tab), Haus-Markierung in Liste und
  Kacheln, Liste „Offline verfügbar“ im Drive-Menü. Die App hält keine
  eigenen Kopien vor: Text sagt „zu Hause im Zwischenspeicher bereithalten“
- Tests: Pin passt/falsch, falscher Hash, 403/404, Weiterleitung, exp,
  Größe, Header nur mit privaten Adressen, Hinweis-Prüfung, Heimnetz-Merker

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016xX1efcZF1f6G9rhmaJNLD
…m erkennen

Der Test „falscher Pin“ erwartete genau den Grund „tls“; je nach JDK wird
der Handshake-Fehler anders verpackt. Jetzt wird die ganze Ursachenkette
(auch unterdrückte Ausnahmen) auf SSL-/Zertifikatsfehler geprüft, und der
Test prüft, worauf es ankommt: kein Ergebnis, keine Datei und keine Anfrage
(samt Signatur) beim Gateway.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016xX1efcZF1f6G9rhmaJNLD
@CallMeTechie
CallMeTechie merged commit 0830bce into main Nov 5, 2026
10 of 11 checks passed
CallMeTechie pushed a commit that referenced this pull request Nov 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants