# 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 – ✅ implementiert
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.