麦式参考 MickerBook Reference

权限

Authorization

也常被叫作:权限控制谁能看授权角色权限AuthZ

你可能会这么说

「让系统按「你是谁」来决定你能看什么、能改什么,管理员能做的别人不能做。」

权限 Authorization

在确认「你是谁」之后,再决定「你能做什么」:能看哪些数据、能改哪些操作。

身份验证(登录)确认了「你是谁」,权限要做的是下一件事:这个身份,被允许做什么。 就算两个人都成功登录了,一个能删订单、一个只能看订单——这就是权限在起作用。

权限有两个最常见的划分维度。按角色(管理员 / 普通用户 / 访客)分,简单好懂,适合人数不多的系统;按对象(我能看自己那份、不能看别人的)分,更细,适合数据归属很强的场景。很多真实系统两者都用:先定角色,再在具体数据上按归属再拦一层。

判断权限做没做对,永远要看后端。前端把「删除按钮」藏起来,只是把界面藏了,不代表真的不能删——只要有人直接调那个删除接口,照样删得掉。真正的权限必须在后端每个接口上核对。这是新手和 AI 最容易漏、也最致命的点:界面上看着没权限,接口上其实没拦。

长什么样 真实可交互,不是截图

订单管理

已登录:admin可删除订单
已登录:访客只读,无删除权限

注意那个「删除订单」按钮:对没权限的人,按钮是禁用的。但更关键的是——就算有人绕过前端直接调删除接口,后端也必须拒绝。这行演示只在画界面的概念层,真正的检查在后端。

拆开看,里面有这几块

  1. 1
    身份 Identity

    你是谁(来自身份验证)。权限的判断前提是这个身份可信。

  2. 2
    角色 / 分组 Role

    把一群身份归为一类,统一授权,比如「管理员」「编辑」「访客」。

  3. 3
    权限 / 操作 Permission

    具体能做的一件件的事:读、写、删、导出、管理成员。

  4. 4
    接口校验 Endpoint check

    在后端每个接口上核对当前身份有没有权限。这层漏了,前端藏按钮等于没藏。

常见的有哪几种

角色权限RBAC

按「管理员 / 普通用户 / 访客」整组授权,简单够用。

用在:人数不多、角色分明的小系统

对象归属Per-object / ACL

精确到「这条数据是谁的、谁能碰」,比如只能改自己的帖子。

用在:数据有明确归属、多人并存

按角色 + 按对象组合Hybrid

先按角色粗分,再在具体数据上细拦。

用在:真实生产系统最常见

容易搞混?这样区分

权限 身份验证 Authentication

身份验证是「你是谁」,权限是「你能做什么」。登录成功不等于能看数据——「所有登录用户都能删订单」就是典型的只做了验证、没做权限。

看 身份验证

什么时候用得上

给后台分角色

管理员能改配置删数据,普通成员只能看不能改。至少先做到「管理员 / 普通用户」两档。

只能看自己的数据

用户只能访问自己创建的内容,不能通过改链接里的 ID 看到别人的。

判断权限是否真生效

不只是看按钮藏没藏,要直接试调那个后端接口,看它拒不拒绝。

你可以这样跟 AI 说

直接复制下面这段,把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了:改哪里、不许动啥、做完交什么。

【任务】给 [项目名] 加权限控制
【角色】定义两档角色:管理员(能改配置、能删除数据)、普通用户(只能看,不能改)
【边界】
  - 权限判断必须在后端每个接口上做,不能只在界面上藏按钮或藏链接
  - 用户只能访问自己创建的内容;通过改地址里的 ID 也不能看到别人的数据
  - 别把权限和登录混在一起写,也不要动现有登录逻辑
【交付】
  1. 分别用一个管理员账号和一个普通账号实测:普通账号去调删除接口、去看别人的数据,把返回结果贴给我
  2. 列出每个受保护接口在后端是怎么做权限判断的(一个接口一段话)
  3. 哪些路径我没验到,你直说

第 1 条是这段的关键:不满足于「按钮藏了」,而是要求用没权限的账号直接调接口、贴返回结果。这才是验权限有没有做在后端的唯一可靠办法。

它说「做好了」,你怎么自己验

这是本站的重头戏。AI 最会的不是写代码,是说「已完成」。这一条,它通常最多做到「主路径」这层:真实用户的正常操作能走通,不靠特殊参数。

要亲眼看到这些,才算数

  • 用普通账号登录,页面上确实看不到管理员才有的按钮(删除、改配置)。
  • 更关键:普通账号直接调用删除接口 / 看别人数据的接口,应该被后端拒绝(报无权限),而不是返回成功。
  • 换管理员账号做同一件事,能成功——证明是权限拦的,不是接口本身坏掉。
  • 尝试通过修改地址里的 ID 去访问不属于自己的数据,应该被拒绝。
  • 登出后再访问受保护接口,应该被拦,不能因为浏览器里还留着状态就放行。

它常这么糊弄你

  • 「权限做好了,删按钮已经藏起来了」——但没权限的账号直接调接口照样能删。界面上藏不叫拦。
  • 「所有登录用户都能访问后台」——这是只做了登录没做权限,或者忘了给接口加判断。
  • 「只有管理员能看这份数据」——但普通用户把地址里的 ID 改成别人那条,就能看到。对象归属这层漏了。
  • 「前端判断了角色再显示」——判断写在前端,可以被人改,等于没拦。权限必须在后端。

权限一般能验到「主路径」层:用两个不同角色的账号各做一遍、并直接调接口看拒绝,就能确认是否真拦住了。往「生产」层走还要处理越权遍历、审计日志、角色变更即时生效这些,不是第一轮的重点。

考考你 选一个你觉得对的

AI 说「删除按钮已经对普通用户隐藏了,权限做好了」。你想验证是否真的安全,最该做什么?