elpatron
43b814d984
- 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
75 lines
2.8 KiB
Markdown
75 lines
2.8 KiB
Markdown
# 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.
|