Chunked upload (uploadLargeFileToTelegram) and chunk merge responses
now also include publicUrl field when urlPrefix is configured, matching
the behavior of regular uploads.
When urlPrefix is configured in page settings, the upload API now
returns a `publicUrl` field in addition to the existing `src` field,
allowing clients to directly access files via the configured public
domain (e.g. R2 custom domain) without needing to reconstruct the URL.
WebDAV upload records now store only the channel identity and object/public paths. Read, delete, move, and rename operations resolve credentials and headers from the current WebDAV channel config by ChannelName, with a legacy metadata fallback so already-created records remain usable.
Constraint: Preserve existing WebDAV object lifecycle behavior while reducing metadata exposure
Rejected: Keep credentials on every file record | expands exposure through metadata reads, backups, and logs
Confidence: high
Scope-risk: moderate
Directive: Keep WebDAV credentials in upload config/env; do not reintroduce per-file credential metadata
Tested: npm test; node deploy/worker/generate-routes.js; npx wrangler deploy --dry-run --config deploy/worker/wrangler.toml; git diff --check
Not-tested: Live WebDAV provider move/delete/read workflow
Cloudflare Workers and Pages already provide the Fetch/Web APIs needed for WebDAV verbs, so the storage integration uses a small local helper instead of adding a Node-oriented WebDAV client. The channel now participates in upload, read, delete, move, rename, channel listing, and runtime config, with chunked uploads explicitly guarded because WebDAV has no portable server-side compose primitive.
Constraint: Preserve Pages Functions and generated Worker deployment paths
Constraint: No new npm dependency for WebDAV client behavior
Rejected: Add a WebDAV npm client | likely Node API/compatibility and package-lock churn
Rejected: Treat WebDAV as External URL only | not a complete storage channel lifecycle
Confidence: high
Scope-risk: moderate
Directive: WebDAV here is third-party storage; keep it distinct from the built-in /dav server settings
Tested: npm test; node worker/generate-routes.js; npx wrangler deploy --dry-run --config worker/wrangler.toml; git diff --cached --check
Not-tested: Live third-party WebDAV provider credentials; Digest-only WebDAV authentication
Replace all new Response calls in commitUpload.js and getUploadUrl.js with
createResponse from uploadTools so that responses include Access-Control-Allow-Origin
and other CORS headers, fixing cross-origin requests.
- Extract shared authentication logic into utils/auth/authCore.js
- Replace enableBasicAuth/enableAuthCode flags with clear authScope enum (ADMIN/USER/EITHER)
- Move all auth-related files into utils/auth/ subdirectory
- Eliminate duplicated admin auth logic between _middleware.js and dualAuth.js
- Fix: user session no longer grants access to admin-only endpoints
- Fix: dualAuth no longer bypasses authCode when admin is not configured
- Update all 17 import references across the codebase
- Preserve original function signatures (userAuthCheck, dualAuthCheck) for zero caller changes
- Add uploadSingleChunkToDiscord function with rate limit handling
- Add uploadChunkToDiscordWithRetry with 429 retry support
- Add mergeDiscordChunksInfo for chunk metadata assembly
- Add handleDiscordChunkedFile for streaming download
- Add fetchDiscordChunkWithRetry for reliable chunk fetching
- Discord uses 9MB chunks (vs 10MB for others) for safety margin
- Support Range requests for video seeking
- Support proxy URL for Discord CDN
- Add HuggingFace API wrapper class (huggingfaceAPI.js)
- Support upload, download, delete operations via HuggingFace Hub API
- Support public repos (unlimited storage) and private repos (100GB limit)
- Private repos: server proxies requests with Authorization header
- Auto-create repo if not exists (with write token)
- Add HuggingFace to auto-retry channel list
- Environment variables: HF_TOKEN, HF_REPO, HF_PRIVATE
- Support load balancing for multiple HuggingFace channels