返回知识库数据与服务 · 账号与安全
权限Permission
权限是「这次请求：主体 × 资源 × 动作 → 允许 / 拒绝」的逐次判定；没授予的就拒绝（fail closed），拒绝时给安全的下一步。
自己试一次：同身份，三个动作，三种结果
成员 #42 对发票 #7 / #99 发起读取、删除、审批。每点一次「校验这次请求」就是一条请求到达服务端。重点看：判定随资源 × 动作变化，以及「审批」这种没授予的能力如何被默认拒绝。
你是成员 #42（已登录——身份由 auth / session 确认）。下面每点一次「校验这次请求」，就是一条请求到达服务端：按 主体 × 资源 × 动作 当场判一次，不缓存、不靠前端藏按钮。
主体成员 #42
资源发票 #7 · 本组
动作读取
本次判定尚未校验
动作 发票 #7本组
还没校验。先猜一下「读取 发票 #7」会得到什么，再点上面的按钮。
请求日志共 0 条 · 每条单独判定
还没有请求。点「校验这次请求」会新增一行。
#42 被授予的能力（最小权限）read · 本组发票deleteapproveread · 他组发票
没列进「授予」的，一律拒绝；需要新能力走申请，而不是默认放开。
原因：还没对「发票 #7 · 读取」发起请求，服务端不会预先放行。下一步：点「校验这次请求」前先猜结果——读自己的、删、审批分别会怎样。对照：每改一次资源或动作，判定都要重跑，权限不缓存到浏览器。
知识点：逐请求判定、默认拒绝、最小权限
面板里刚操作过的现象，对应权限最常被混在一起的几条原则。
- 每次请求单独判
判定对象是 (主体, 资源, 动作) 这个三元组，不是「这个人」。#42 读 #7 允许，不代表 #42 能删 #7、也不代表能读 #99。浏览器不缓存判定结果，下一请求照常重判。
- 不确定就拒绝（fail closed）
策略里没写「成员可审批」，approve 不是被显式拒绝、是压根没授予——系统默认 DENY。反过来「默认放行」是漏洞：多写一个动作、多加一个字段都可能变成越权。
- 最小权限
只授予完成工作所需的最小能力集。#42 只拿到「读本组发票」，删除 / 审批 / 跨组读取一律不给；需要时走申请审批，而不是预先放开。
- 拒绝也要有安全的下一步
无权时不暴露受保护字段（涂黑而非预加载再隐藏）、不泄露资源是否存在；同时给出可操作的下一步——申请权限或回公开页——并记录审计。
三种写法，同一条策略
面板里那条「read 本组发票=允许、其余拒绝」的策略，常用三种等价模型表达。选哪种取决于资源量和角色稳定度，判定结果应当一致。
能力列表 Capability按主体列「能做什么」#42 → [read: invoice(本组)]
适合按用户发牌，能力本身可传递；撤销要逐个收回。invoice #7 → read: [本组成员], delete: [], approve: []
适合资源边界清楚、逐资源管控；规则多时需要分组或继承。角色=成员 → [read: invoice(本组)]；#42 分配成员
适合岗位稳定、批量授权；具体角色如何打包见 role 词条。 三种模型可以互换；不管选哪种，服务端都要在每条请求上重新求值，并以「未命中→拒绝」收尾。
什么时候拦，什么时候别误伤
权限保护会暴露他人数据或改动状态的请求；公开内容不该被登录墙或越权策略误伤。
必须逐请求判定读取他人范围的数据、删除 / 审批 / 导出等写动作，以及任何带 id 的资源（防 IDOR：不能因为知道 id 就能访问）。
别误伤公开内容公开教程、落地页可匿名读；权限只拦受保护资源，且拒绝文案说清边界，不把所有人都弹去登录。
同一件事：正例与反例
目标都是「成员 #42 想审批发票 #7」。差异只在：没授予的能力，服务端是默认拒绝还是默认放行；拒绝时给不给下一步。
approve 请求到达，服务端查策略发现无此能力 → 返回 403 / 权限错误，不改动资源、不暴露字段，前端提示「需审批权限」并提供申请入口，审计日志记下 (主体 #42, invoice #7, approve, deny-default)。
fail closed：没授予就是拒绝，文案区分「未授予」与「无权」。策略只写了 read / delete，approve 没匹配到任何规则就被当成「非禁止即允许」放行；或前端藏掉审批按钮，接口照做不误。换一个角色或新动作，立刻越权。
应改成「未命中→拒绝」并服务端重判；前端隐藏只是体验，不替代鉴权。快速自测
成员 #42 能读 #7，现在系统新增一个「导出 #7」的动作，策略里还没写这条规则。服务端应该怎么判？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。