elpatron
262cffe4a6
- Scripts: start-webdav.cmd, stop-webdav.cmd (echo messages, REM comments) - Server: server.js (console.log, HTTP error messages) - Token tools: token-test.js, token-refresh.js - Other: auth-poc.js, debug-name-decrypt.js, internxt-client.js, upload.js - Docs: README, .env.example, docs/*.md Made-with: Cursor
75 lines
2.7 KiB
Markdown
75 lines
2.7 KiB
Markdown
# WebDAV Server Architecture
|
||
|
||
## Recommended Approach: Adapter (not Proxy)
|
||
|
||
The WebDAV server is an **adapter**: it implements the WebDAV protocol and translates requests into Internxt Drive API + Network calls. It does **not** forward to another WebDAV server.
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph Client [WebDAV Client]
|
||
Finder[Finder/Cyberduck]
|
||
Rclone[Rclone]
|
||
end
|
||
|
||
subgraph Adapter [WebDAV Adapter]
|
||
WebDAV[WebDAV Server]
|
||
Mapping[Path to 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
|
||
```
|
||
|
||
## Data Flow
|
||
|
||
| WebDAV Request | Internxt Operation |
|
||
|----------------|-------------------|
|
||
| PROPFIND (directory listing) | Storage.getFolderContentByUuid |
|
||
| GET (read file) | File metadata → Network.download → Decrypt |
|
||
| PUT (write file) | Encrypt → Network.upload → createFileEntry |
|
||
| MKCOL (create folder) | Storage.createFolderByUuid |
|
||
| DELETE | Trash or permanent delete |
|
||
| MOVE | Storage.moveFileByUuid / moveFolderByUuid |
|
||
|
||
## Complexity
|
||
|
||
- **Simple:** PROPFIND, MKCOL – Drive API only, no encryption
|
||
- **Medium:** DELETE, MOVE – Drive API
|
||
- **Complex:** GET, PUT – Bridge/Network + mnemonic encryption
|
||
|
||
drive-web uses `Network.client` (Bridge) and `NetworkFacade` for up/download. Bridge credentials come from the user session.
|
||
|
||
## Implementation Order
|
||
|
||
1. **Phase 1:** PROPFIND (list directory) – ✅ implemented
|
||
2. **Phase 2:** MKCOL, DELETE, MOVE – ✅ implemented
|
||
3. **Phase 3:** GET (download) – Bridge + decryption – ✅ implemented
|
||
4. **Phase 4:** PUT (upload) – Encryption + Bridge – ✅ implemented
|
||
|
||
### Name Decryption
|
||
|
||
Internxt uses zero-knowledge encryption. The API returns encrypted names (`name`). When `plain_name` is missing, the server can decrypt names with `CRYPTO_SECRET2` (or `CRYPTO_SECRET`) – analogous to drive-web `aes.decrypt` logic with `secret2-parentId`/`secret2-folderId`. Without a set secret, raw (encrypted) names are used.
|
||
|
||
## Token vs Bridge Credentials
|
||
|
||
- **Drive API:** Uses `xNewToken` (Authorization: Bearer)
|
||
- **Network/Bridge:** Requires `bridgeUser` + `userId` (from user credentials) and mnemonic for encryption
|
||
|
||
**Bridge credentials from refreshUser:** The `/users/refresh` endpoint returns `user` (UserResponseDto) with:
|
||
- `bridgeUser` – User email
|
||
- `userId` – hashed with SHA256 and used as Bridge password
|
||
- `bucket` – Bucket ID for uploads
|
||
- `mnemonic` – for file encryption
|
||
- `rootFolderId` – Root folder UUID
|
||
|
||
Thus the browser token (via refreshUser) provides all data needed for Drive API and Bridge.
|