Initial commit: WebDAV-Adapter für Internxt Drive

- Browser-Token-Auth (INXT_TOKEN, INXT_MNEMONIC)
- Phase 1: PROPFIND (Verzeichnis auflisten)
- Drive API + Pfad-Resolver
- Dokumentation: Auth, Architektur, WSL

Made-with: Cursor

docs/webdav-architektur.md

@@ -0,0 +1,74 @@
+# 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.
+
+```mermaid
+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
+
+1. **Phase 1:** PROPFIND (Verzeichnis auflisten) – ✅ implementiert
+2. **Phase 2:** MKCOL, DELETE, MOVE
+3. **Phase 3:** GET (Download) – Bridge + Entschlüsselung
+4. **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.