应使用服务端签发的一次性签名token校验请求合法性：前端先调用/api/token获取含book_id、时间戳和HMAC签名的token，播放接口校验其有效期（≤60秒）、book_id匹配及签名正确性，PHP通过generatePlayToken生成、verifyPlayToken验证token，并由PHP流中转音频文件实现鉴权。
PHP 调用听书插件时如何验证请求来源
直接暴露 play.php 或 api/v1/audio?book_id=123 这类接口，等于把音频资源门禁钥匙挂在门口。攻击者只要抓到 URL，就能绕过前端限制批量下载。必须在服务端强制校验每次请求的合法性。
核心思路：不依赖前端传来的 Referer 或 User-Agent（极易伪造），而是要求每次调用携带服务端签发的一次性凭证。
- 前端播放前先请求
/api/token?book_id=456，后端生成含时间戳、book_id 和签名的 JWT 或 Hmac 字符串 - 播放接口（如
/api/play）必须校验该 token 是否未过期、book_id 匹配、签名正确 - token 有效期建议 ≤ 60 秒，且单次有效（用完即废）可防重放
如何用 PHP 实现带签名的临时播放链接
避免把音频文件路径直接暴露给浏览器，应由 PHP 输出流中转，并在输出前完成权限检查。关键不是“隐藏 URL”，而是“每次访问都重新鉴权”。
function generatePlayToken($bookId, $userId = 0) {
$expires = time() + 60;
$payload = compact('bookId', 'userId', 'expires');
$secret = $_ENV['AUDIO_SIGN_KEY'] ?? 'your_strong_secret';
$hmac = hash_hmac('sha256', json_encode($payload), $secret);
return base64_encode(json_encode($payload) . '|' . $hmac);
}
function verifyPlayToken($token) {
$decoded = base64_decode($token);
if (false === $decoded || !str_contains($decoded, '|')) return false;
[$json, $hmac] = explode('|', $decoded, 2);
$payload = json_decode($json, true);
if (!$payload || !isset($payload['expires']) || $payload['expires'] < time()) return false;
$secret = $_ENV['AUDIO_SIGN_KEY'] ?? 'your_strong_secret';
$expected = hash_hmac('sha256', $json, $secret);
return hash_equals($expected, $hmac); // 防时序攻击
}
注意：hash_equals() 必须使用，直接用 === 比较签名会引发时序侧信道风险。
立即学习“PHP免费学习笔记（深入）”；
为什么不能只靠 .htaccess 或 Nginx 屏蔽直接访问
这类静态规则只能拦住“没走 PHP 的直连”，但对通过 file_get_contents()、cURL 或伪造 Referer 的脚本完全无效。更危险的是：一旦攻击者拿到一个合法 token，就能无限次调用播放接口——除非你在 PHP 层做频控或绑定 IP。
- 音频文件应放在
webroot外（如/var/audio/），绝不放public/下 - Nginx 可加
location ~ \.mp3$ { deny all; }防误配置泄露 - 但真正起作用的只有 PHP 中的
verifyPlayToken()+ 文件流输出逻辑
常见被忽略的边界问题
防护失效往往不出在主流程，而在边缘场景：
- book_id 未做整型过滤，导致 SQL 注入或路径穿越（如传
book_id=1%2F..%2Fetc%2Fpasswd） - token 解析未校验 JSON 结构，
json_decode()失败后继续执行，可能绕过签名检查 - 音频文件名拼接未过滤特殊字符，
readfile("/var/audio/{$bookId}.mp3")可能被注入路径 - 未设置
header('Content-Disposition: inline; filename="audio.mp3"')，部分浏览器会缓存响应，导致 token 复用
音频资源不像普通 API，一次非法调用就等于直接损失内容资产。所有输入必须当作不可信处理，所有输出必须经鉴权链路 —— 即使是同一个用户，每次播放也要走一遍 token 签发与核验。
