Files

elpatron 262cffe4a6 Translate all user-facing output to English

- 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

2026-02-28 16:37:28 +01:00

2.7 KiB

Raw Blame History

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.

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

Phase 1: PROPFIND (list directory) – ✅ implemented
Phase 2: MKCOL, DELETE, MOVE – ✅ implemented
Phase 3: GET (download) – Bridge + decryption – ✅ implemented
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.

2.7 KiB Raw Blame History Unescape Escape