REST API 返回 401 或 403，正文包含 The consumer isn't authorized to access %resources。这说明请求大多已经到达 Magento，Token 也可能被识别，但当前身份没有目标 ACL 资源。不要反复重新生成 Token，先确认“谁的 Token、访问哪个资源”。

curl -sk -D /tmp/api.headers  -H 'Authorization: Bearer REDACTED'  'https://shop.example.com/rest/V1/orders/000000123'  -o /tmp/api.json
cat /tmp/api.headers
cat /tmp/api.json

四种身份不要混用

  • Admin Token：权限来自管理员角色；
  • Customer Token：只能访问客户 self 资源；
  • Integration Token：权限来自 Integration Resources；
  • 匿名请求：只允许 anonymous 资源。

用 Customer Token 调管理订单接口，即使 Token 有效也会被拒绝。先从 Token 创建流程确认身份类型，不要在日志中输出 Token。

自定义接口的 resource 必须存在

<route url="/V1/vendor/item/:id" method="GET">
 <service class="VendorModuleApiItemRepositoryInterface" method="getById" />
 <resources>
  <resource ref="Vendor_Module::item_read" />
 </resources>
</route>

对应 ACL 要在 etc/acl.xml 定义，ID 大小写完全一致。把 resource 临时改成 anonymous 虽能绕过错误，却会暴露内部数据。

grep -Rni 'Vendor_Module::item_read' app/code/Vendor/Module/etc
bin/magento cache:clean config
bin/magento setup:di:compile

Integration 修改权限后重新激活

后台检查 Resources 是 All 还是 Custom，并确认目标资源节点已勾选。某些变更需要重新激活才能得到与权限一致的 Token。先在测试 Integration 验证，不要直接替换生产系统凭据。

最后用一个允许接口和一个明确禁止的接口做正反测试：前者应返回数据，后者仍被拒绝。若两者都成功，说明 ACL 放得过宽；若两者都失败，继续检查 Token 身份或配置缓存。

Store Code 路径错误也会造成误判

/rest/V1/... 使用默认 Store；多店铺接口需要确认是否应使用 /rest/zh_cn/V1/...。Store Code 不会替代 ACL，但会改变网站范围、商品可见性和配置结果。权限恢复后，再用目标 Store Code 验证业务数据是否正确。

保留可审计的最小权限

Integration 不应因为排障临时选择 All 后一直保留。记录接口与 ACL resource 的对应表，只勾选所需读取或写入资源，并在回归测试中确认写接口仍受限制。