Files

elpatron 43b814d984 Phase 2: MKCOL, DELETE, MOVE implementiert

- resolveResource() für Pfad→UUID (Datei/Ordner)
- MKCOL: Ordner anlegen (createFolderByUuid)
- DELETE: Datei/Ordner löschen
- MOVE: Verschieben + Umbenennen mit Destination-Header

Made-with: Cursor

2026-02-28 11:06:56 +01:00

2.8 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
Phase 4: PUT (Upload) – Verschlüsselung + Bridge

Hinweis: Ordnernamen

Internxt nutzt Zero-Knowledge-Verschlüsselung. Die API liefert verschlüsselte Namen (name). Die Pfadauflösung funktioniert, weil WebDAV-URLs diese Namen enthalten. Eine spätere Phase kann Namensentschlüsselung mit Mnemonic ergänzen (drive-web Crypto-Logik).

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.8 KiB Raw Blame History Unescape Escape