头像权限控制指对上传、更新、删除操作的访问控制，需在控制器入口处硬性校验身份与权限，禁止依赖前端限制；文件存储须隔离且路径脱敏，读取与清理均需二次权限验证。
用户头像权限不是指“谁能看头像”，而是指“谁有权上传、更新、删除头像”——这个动作本身需要明确的访问控制，否则任意用户都可能覆盖他人头像，或未授权者批量上传恶意文件。File Access控制器法，就是把头像操作当作受控的文件访问行为，用统一的权限策略拦截非法请求，而不是靠前端隐藏按钮或JS校验来“假装安全”。
头像操作必须绑定身份与权限
用户登录后，系统应确认两点：当前会话是否有效（如JWT未过期、Session未失效），以及该用户是否具备执行头像操作的权限标识（如update_own_avatar）。仅验证登录不等于允许上传；管理员能改任何人头像，普通用户只能改自己的——这种差异需在控制器入口处硬性判断，不能留到模型层或视图层补救。
控制器中做前置权限拦截
在处理头像上传/删除的Action开头，立即调用权限检查逻辑：
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
- Yii2示例：
if (!Yii::$app->user->can('update_own_avatar', ['userId' => $model->id])) { throw new ForbiddenHttpException(); } - Laravel示例：
$this->authorize('update', $user);（配合Policy自动比对当前用户ID与路由参数） - Spring Security示例：用
@PreAuthorize("principal.id == #userId or hasRole('ADMIN')")注解约束方法参数
关键点：权限判断必须在接收文件、解析表单、调用模型验证之前完成。否则攻击者可绕过前端限制，直接POST一个伪造的avatar字段，触发后续存储逻辑。
文件路径与存储权限分离管理
头像实际保存路径（如uploads/avatars/123456_abc789.jpg）不应暴露用户ID或敏感信息，更不能让权限逻辑依赖路径字符串。正确做法是：
- 数据库只存相对路径或唯一哈希标识（如
avatar_hash: "x9f2a1b"），由服务端映射到真实磁盘位置 - 所有头像文件统一存入隔离目录（如
storage/app/avatars/），Web服务器禁止直接执行该目录下的PHP/JS文件 - 读取头像时，不返回物理路径，而是经由控制器路由中转（如
/avatar/{hash}），并在中转逻辑里再次校验访问权限（例如：公开头像可直链，私密头像需登录且匹配所属用户）
旧头像清理需同步权限校验
更新头像时删除旧文件，不是简单的unlink()或Storage::delete()。必须先确认当前操作者有权删除该头像所归属的用户记录：
- 若用户A尝试提交B的用户ID并上传头像，控制器应拒绝——即使数据库里B的avatar字段可写，也不代表A有权限删B的旧文件
- 删除前查一次目标用户是否存在、状态是否正常，并比对当前登录用户ID与目标用户ID（或角色权限）
- 失败时记录审计日志，包括操作者IP、时间、目标用户ID、拒绝原因
