权限核对 · 分项说明
概念说明
权限核对是在请求真正执行的位置，把动作、对象和当前许可逐项对照，判断这一次操作能否被执行；它靠执行侧的再次判定成立，而不靠界面是否显示入口。判断失误的后果是把隐藏按钮当成防护，直接访问同一动作时仍可能被放行，或者只凭曾经授予就放过已收窄的许可。正确做法是在实际执行前重新核对，按最小范围确认对象，并在拒绝时记录缺少的是哪一项许可。
判断方法
把一次拒绝直接当成缺少许可，常导致申请比所需更大的范围；若扩大后仍失败，排障方向被带偏，还留下多余授权。要区分这两种情况，可在可回退的测试对象上用测试身份做三步：先记录失败时的对象、动作、身份与返回信息，再只补上覆盖该对象该动作的最小一项许可，随后重做同一操作。补授后通过，说明此前确实是这一项许可缺口；补授后仍失败，说明缺口不在该条授权，应撤回补授，转查对象状态、审批流程或客户端限制。这条验证只在有权修改授权的测试环境进行，不通过扩大生产账号权限来试探，也不把补授结果当作其他动作也获许可的依据。
适用边界
有服务以自身身份代替用户执行时，被判定的是代理身份，不是发起者；把放行或拒绝记到用户账号上，会在错误的授权对象上调整设置，问题没解决还扩大了权限面。这类代操作、共享凭据或临时令牌的场景只适合记录请求现象，不适合反推用户许可。核对结论也不能用于审计或合规判断，它不评价授权范围是否最小、分配是否合理。结论有明确时刻，令牌过期、定时任务或授权变更后旧结果不再成立；并发请求下同一操作可能因状态变化而结果不同，单次核对不足以断言稳定。
读者评论
笑死，我照着弄了半天，结果发现是我自己看错了。
谢谢，终于搞懂了一直没弄明白的那个点。
看完就去翻设置，果然有一项一直开着没关。
请问一下，这类经验对其他类型的情况也通用吗？
道理是这么个道理，真上手还是得靠自己慢慢找感觉。