elpatron
406e31f338
- 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
75 lines
2.9 KiB
Markdown
75 lines
2.9 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 – ✅ implementiert
|
||
4. **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.
|