资源下载权限怎样设计更稳

权限判断要落在文件服务之前

资源下载的权限问题，表面上是“谁能点这个链接”，实际上是“文件放在哪、谁有资格拿、下载行为如何被记录”三件事的叠加。如果只在前端隐藏按钮，或者只给文件加一个难以猜测的URL，都不能算权限控制——前者可以被绕过，后者一旦链接泄露就完全失控。

设计下载权限时，先明确资源本身的属性：是公开给所有访客，还是只给登录用户，或者只给特定角色、特定用户组，甚至需要管理员逐条审批。不同的资源类型对应不同的判断逻辑，混在一起处理最容易出漏洞。

数据表结构决定权限判断的边界

把资源存储方式、访问等级、指定用户和下载申请分开保存，是让权限逻辑清晰的基础。一张表只负责记录资源本身的信息，另一张表记录资源和用户或角色之间的授权关系，申请记录单独存放。这样权限变更时不需要改动资源表，也不会因为申请流程的调整而影响已有资源的正常下载。

一个可用的最小结构至少包含：

• 资源表：存储文件路径、存储类型、是否公开、上传时间等基础信息；
• 授权表：存储资源ID、用户ID或角色ID、授权类型（直接授权或申请通过）、过期时间；
• 申请记录表：存储申请人、申请时间、处理状态、处理结果。

判断下载权限时，先查资源是否公开，再查当前用户是否在授权表中，最后检查申请状态。顺序不能颠倒，因为公开资源不需要走申请流程，而私有资源即使有申请记录，也必须确认申请已通过且未过期。

下载入口统一走控制器

资源文件不应该直接放在Web可访问目录下，也不应该在页面里输出真实的文件路径。更稳妥的做法是让所有下载请求都指向同一个控制器方法，由控制器完成权限验证后再决定是输出文件内容还是返回错误信息。

判断逻辑可以概括为：接收资源ID和当前用户信息，查询资源状态，检查用户是否具备下载资格，确认通过后读取文件并输出。任何一步不满足，都返回明确的提示，而不是直接暴露文件地址。

以下是一段简化的原生PHP处理逻辑，展示权限判断的基本流程：

```php
public function download($resourceId, $user)
{
$resource = $this->findResource($resourceId);
if (!$resource) {
exit('资源不存在或已下架');
}

if ($resource['is_public'] == 1) {
$this->outputFile($resource);
return;
}

if (!$user || !$user['is_login']) {
exit('请先登录后再下载');
}

$grant = $this->findGrant($resourceId, $user['id']);
if ($grant && $grant['status'] == 'approved' && $grant['expires_at'] > date('Y-m-d H:i:s')) {
$this->outputFile($resource);
return;
}

$this->createApplyRecord($resourceId, $user['id']);
exit('当前无下载权限，已为你提交申请，请等待管理员审核');
}
```

这段代码的关键在于：每个分支都有明确的出口，不会出现“没有权限却继续执行”的穿透情况。实际项目中，文件读取和输出部分还需要考虑文件是否存在、是否被移动、存储类型是本地还是远端等问题。

容易出错的位置

权限设计最常见的漏洞出现在三个地方。

第一，文件路径直接暴露在HTML源码或JavaScript中。即使页面上的下载按钮做了权限判断，只要浏览器开发者工具里能看到真实地址，用户就可以绕过页面直接访问。解决方法是页面只输出下载入口的URL（如 download.php?id=123），真实路径只存在于服务器端。

第二，授权判断只做了“是否登录”的检查，没有区分角色或具体授权记录。登录用户和普通访客的权限不同，管理员和编辑的权限也不同，不能用一个布尔值概括所有情况。

第三，申请审核通过后没有设置有效期，或者过期后没有重新校验。资源下载授权应该是可撤销、可过期的，否则离职员工或不再相关的用户会一直保留下载资格。

检查时，可以分别用未登录状态、已登录但无授权状态、已授权但已过期状态、正常授权状态去测试同一个下载入口，观察返回结果是否与预期一致。同时检查下载记录是否写入日志，至少包含用户ID、资源ID、下载时间和IP地址，便于事后追溯。

后台要能维护，前台才算完成

前台下载功能做完，只是整个流程的一半。后台需要能查看申请列表、通过或拒绝申请、设置授权有效期、手动撤销某个用户的下载权限。如果这些操作只能直接改数据库，那这个功能对维护者来说就是不可用的。

申请列表至少要显示申请人的基本信息、申请的资源名称、申请时间和当前状态。审核操作要区分“通过”和“拒绝”，通过后自动写入授权表，拒绝时可以填写原因并反馈给申请人。这些操作都应该在后台界面中完成，而不是依赖SQL语句。

另外，资源上传时就应该区分公开和私有，而不是上传后再去修改属性。上传界面中设置一个“是否公开”的选项，后台列表里能按公开/私有筛选资源，这样资源数量多了以后仍然可以快速定位问题。

异常处理与后续扩展

下载过程中可能出现文件丢失、存储服务不可用、授权记录异常等情况。控制器中要捕获这些异常并返回可读的错误信息，而不是让用户看到空白页面或服务器错误。日志中要记录异常发生的上下文，方便排查是权限判断的问题还是文件读取的问题。

后续如果加入下载次数统计，可以在控制器输出文件前写入一条下载记录，统计时直接查询记录表即可。如果加入过期链接机制，可以在授权表中增加过期时间字段，下载时判断当前时间是否超过有效期。这些扩展都不需要改动已有的权限判断逻辑，只需要在现有基础上增加字段和判断条件。

权限设计的目标不是把所有入口都封死，而是让每一次下载行为都有依据、可追溯、可撤销。做到这三点，资源中心才能长期稳定运行，后续维护时也不需要重新摸索当初的设计意图。