Watch progress and unlocking:
- Player samples the playhead and reports the ranges actually played,
so skipped sections earn no credit and early plays are not lost
- Server merges ranges into compact segment rows; progress never regresses
- Single 80% unlock rule enforced server-side (lib/watch-progress.ts);
the Unlock button and automatic unlock now agree
- Lock state and progress bar update live from each progress save
- Playlist is derived from the video, so unlocks work for shared
playlists and for links from watch history and liked videos
- First/previous video decided by playlist position, not index numbers
Access control:
- Video API and HLS/MP4 routes require a signed-in viewer who is
enrolled and has the video unlocked; thumbnails require sign-in
- Enrolment sync reads course codes from the allow-list, not the request
- /api/admin/meta is admin-only
- Account status, role and levels are re-checked from the database
during a session, so deactivated students lose access within a minute
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
- Upgrade next 16.0.3 -> 16.3.5 and react/react-dom 19.2.0 -> 19.3.0
(CVE-2025-55182 / CVE-2025-66478 unauthenticated RCE), next-auth -> 4.24.15
- Require admin role on /api/users, /api/courses and /api/enrollments,
which were unauthenticated
- Replace ALLOWED_ADMINS checks that allowed any signed-in user when the
variable was empty with the role-based requireAdmin
- Sanitize upload filenames, restrict thumbnail extensions, store edited
thumbnails in UPLOADS_DIR, tighten traversal checks in file routes
- Dockerfile: Node 22, pinned pnpm, non-root user, critical audit gate
- Compose: read-only rootfs, dropped caps, no-new-privileges, Postgres
password from env
- Exclude .env from Docker build context; add security headers
- Deploy with git reset --hard instead of git pull
- Remove stale package-lock.json
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
req.formData() parsed the entire multipart body into RAM, so large
uploads (1.6GB+) OOM-killed the server. Bridge the web Request body to
a Node stream and parse it with formidable, which writes the file to
disk as it arrives:
- Temp dir is /uploads/tmp (same filesystem as the destination) so the
post-parse move is an atomic rename, not a second multi-GB write
- Mark the bridged request as chunked when a proxy strips
content-length, otherwise formidable assumes an empty body
- Track formidable temp files via fileBegin so aborted uploads get
their partial files cleaned up
- Remove the dead formidable branch gated on (req as any).req, which
is always null in the App Router
Also fix the nginx example in VPS_UPLOAD_CONFIG.md: client_max_body_size
was 1024M, below the app's 2.5GB limit, and would 413 large uploads at
the proxy before they reached the app.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
twotalesanimation