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>
Video records store url = /uploads/videos/<id>.mp4, but nothing served
that path: Next.js only serves static files from public/, so the
player's MP4 fallback 404'd and videos were unplayable until HLS
transcoding finished. (Thumbnails hit the same problem historically —
see scripts/update-thumbnail-urls.ts.)
Add a route handler at the exact stored URL so no DB migration is
needed. Unlike the HLS route it streams from disk via createReadStream
instead of buffering the file, and implements HTTP Range requests
(206/416, open-ended and suffix ranges) — browsers require ranges for
<video> seeking, and files can be multi-GB.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Cast the transcoder upload body to node:stream/web ReadableStream;
the DOM ReadableStream type lacks the async-iterator members
Readable.fromWeb expects
- Exclude transcoder/ and transcoder-remote/ from the root tsconfig:
they are standalone sub-projects with their own tsconfig and
dependencies (e.g. archiver) that aren't installed in the root
node_modules, so next build's typecheck can never resolve them
Co-Authored-By: Claude Fable 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