Files

elpatron 406e31f338 Namensentschlüsselung, Phase 4 PUT, Bridge-Fix, Debug-Tools

- name-decrypt.js: AES-Entschlüsselung für Datei-/Ordnernamen (CRYPTO_SECRET2)
- path-resolver.js: getPlainName für alle Pfad-Operationen
- upload.js: PUT mit Verschlüsselung, Bridge API v2
- download.js: Bridge 400-Fix (x-api-version, Header)
- debug-name-decrypt.js: Test-Skript für Namensentschlüsselung
- docs: CRYPTO_SECRET/CRYPTO_SECRET2 dokumentiert

Made-with: Cursor

2026-02-28 11:49:26 +01:00

2.9 KiB

Raw Blame History

WebDAV-Server Architektur

Empfohlener Ansatz: Adapter (nicht Proxy)

Der WebDAV-Server ist ein Adapter: Er implementiert das WebDAV-Protokoll und übersetzt Anfragen in Internxt Drive API + Network-Aufrufe. Es wird nicht zu einem anderen WebDAV-Server weitergeleitet.

flowchart LR
    subgraph Client [WebDAV Client]
        Finder[Finder/Cyberduck]
        Rclone[Rclone]
    end

    subgraph Adapter [WebDAV Adapter]
        WebDAV[WebDAV Server]
        Mapping[Path zu UUID]
        Crypto[Encrypt/Decrypt]
    end

    subgraph Internxt [Internxt Backend]
        DriveAPI[Drive API]
        Network[Bridge/Network]
    end

    Finder -->|PROPFIND GET PUT| WebDAV
    WebDAV --> Mapping
    Mapping --> DriveAPI
    WebDAV --> Crypto
    Crypto --> Network

Datenfluss

WebDAV-Anfrage	Internxt-Operation
PROPFIND (Verzeichnisinhalt)	Storage.getFolderContentByUuid
GET (Datei lesen)	File-Metadaten → Network.download → Entschlüsseln
PUT (Datei schreiben)	Verschlüsseln → Network.upload → createFileEntry
MKCOL (Ordner anlegen)	Storage.createFolderByUuid
DELETE	Trash oder permanent delete
MOVE	Storage.moveFileByUuid / moveFolderByUuid

Komplexität

Einfach: PROPFIND, MKCOL – nur Drive API, keine Verschlüsselung
Mittel: DELETE, MOVE – Drive API
Aufwändig: GET, PUT – Bridge/Network + Mnemonic-Verschlüsselung

Die drive-web nutzt Network.client (Bridge) und NetworkFacade für Up-/Download. Die Bridge-Credentials kommen aus der User-Session.

Implementierungsreihenfolge

Phase 1: PROPFIND (Verzeichnis auflisten) – ✅ implementiert
Phase 2: MKCOL, DELETE, MOVE – ✅ implementiert
Phase 3: GET (Download) – Bridge + Entschlüsselung – ✅ implementiert
Phase 4: PUT (Upload) – Verschlüsselung + Bridge – ✅ implementiert

Namensentschlüsselung

Internxt nutzt Zero-Knowledge-Verschlüsselung. Die API liefert verschlüsselte Namen (name). Wenn plain_name fehlt, kann der Server mit CRYPTO_SECRET2 (oder CRYPTO_SECRET) Namen entschlüsseln – analog zur drive-web aes.decrypt-Logik mit secret2-parentId/secret2-folderId. Ohne gesetztes Secret werden die rohen (verschlüsselten) Namen verwendet.

Token vs. Bridge-Credentials

Drive API: Nutzt xNewToken (Authorization: Bearer)
Network/Bridge: Braucht bridgeUser + userId (aus User-Credentials) und Mnemonic für Verschlüsselung

Bridge-Credentials aus refreshUser: Der Endpoint /users/refresh liefert user (UserResponseDto) mit:

bridgeUser – E-Mail des Nutzers
userId – wird mit SHA256 gehasht und als Bridge-Passwort genutzt
bucket – Bucket-ID für Uploads
mnemonic – für Dateiverschlüsselung
rootFolderId – Root-Ordner-UUID

Damit liefert der Browser-Token (via refreshUser) alle nötigen Daten für Drive API und Bridge.

2.9 KiB Raw Blame History Unescape Escape