17370845950

真正可控的做法是让的src指向后端鉴权接口，服务端对每个视频请求实时校验session/token，并返回流式响应；前端不可靠拦截无效，静态文件必须禁用直接访问。

视频资源本身不支持“登录后才能播放”的权限控制

HTML5 的 标签只是播放器外壳，它无法主动校验用户登录状态。所谓“需要登录才能播放”，本质是**服务端拒绝未授权请求**，而不是前端拦住 标签。如果你把视频 URL 直接写死在 src 里，任何人拿到这个 URL 都能绕过页面直接访问——登录态只存在于浏览器上下文， 发起的资源请求默认携带当前域的 Cookie（如果配置了 credentials），但前提是服务端真正在验证它。

关键：用服务端接口动态返回视频流，并校验 session / token

真正可控的做法是让 的 src 指向一个后端接口（如 /api/video/123），该接口在返回视频数据前检查用户身份。常见实现要点：

• 前端确保请求携带凭证：若用 Cookie 登录，需在 加载时浏览器自动带上；若用 JWT，得改用 fetch + URL.createObjectURL() 播放（因为 src 不支持手动加 header）
• 后端响应必须设置正确 MIME 类型（如 video/mp4）和流式传输头（Content-Range、Accept-Ranges: bytes），否则进度条拖动、暂停恢复会失效
• 不要返回 302 跳转到公开地址——这等于把权限校验形同虚设

避免前端“假权限”：别用 JS 拦 play() 或隐藏控件

以下做法无效且危险：

• 监听 play 事件再 event.preventDefault() —— 用户可禁用 JS 或直接右键“另存为”源地址
• 把视频地址藏在 JS 变量里、用 base64 编码或拼接字符串 —— DevTools 里 Network 面板一眼可见真实请求
• 用 Canvas 帧捕获或 WebRTC 中转 —— 增加复杂度，仍无法阻止录屏或抓包

唯一可靠的防线在服务端：对每个 GET /api/video/* 请求做实时鉴权，并限制 Referer、User-Agent 或签名校验（如临时 token + 过期时间）。

进阶防护：临时签名 URL 或 DRM（但成本高）

如果内容敏感（如付费课程），可考虑：

• 生成带签名和过期时间的临时 URL，例如 /video/abc123?token=xxx&exp=171xxxxx，后端验证签名和时间戳
• 接入 Widevine / FairPlay 等 DRM 方案，但需打包加密视频、申请证书、适配 EME API，普通网站极少采用
• 使用 HLS 分片 + 每个 .ts 请求都校验 token —— 更细粒度，但也更依赖服务端性能

注意：所有这些方案的前提仍是——视频文件不能放在 Nginx/Apache 的静态目录下直接可访问；必须经过应用服务器路由，才能插入鉴权逻辑。