MediaWiki 1.34同配置实例正常时获取API登录令牌报错排查

故障核心逻辑 #

触发规则：MediaWiki API入口在加载任何业务模块（包括获取登录令牌的query模块）之前，会先校验当前请求上下文的基础read权限，只要校验不通过，就会直接抛出readapidenied报错，不会执行后续的业务流程。

该故障和前端页面可正常访问的状态并不冲突，两者的权限校验链路是独立的：前端页面的权限判断可以命中长期缓存的公开页面快照，而API请求的权限判断会优先读取实时权限规则或对应缓存的权限快照，因此很容易出现“前端正常、API全被拦截”的错配状态。

已验证无差异项 #

结合故障场景，可提前排除的无效排查方向包括：

• 实例核心源码无逻辑差异（全文件diff校验通过）
• 静态配置文件无实质逻辑差异（从运行正常的站点整套复制配置文件到故障站）
• 站点基础功能（页面访问、用户登录）运行正常

定向排查步骤 #

1. 优先排除运行时缓存污染 #

多实例部署场景下，静态配置文件的变更不会自动同步清空PHP进程、缓存服务中的运行时状态，这是这类跨实例配置一致但功能异常的最高发原因：

• 从服务器命令行直接执行MediaWiki自带脚本，跳过web层的缓存链路，验证权限规则本身是否正确：
  php maintenance/run.php eval -- 'global $wgUser; $wgUser = User::newFromName( null ); echo $wgUser->isAllowed( "read" ) ? "匿名权限校验通过" : "匿名权限校验失败";'
• 如果命令行执行结果为校验通过，说明web服务进程内的权限缓存被旧值污染，直接清空故障实例对应的所有运行时缓存即可：包括服务器本地文件缓存目录、PHP进程内的Opcode/APC缓存、共用Redis/Memcached实例中对应wikiB前缀的所有缓存键。

2. 排查数据库层的权限覆盖规则 #

MediaWiki存在多个可绕过静态配置文件、直接在数据库层覆盖权限规则的入口，这类残留配置不会因为复制配置文件而消失：

• 检查user_groups表中是否存在用户ID为0（匿名用户上下文）的残留记录——MediaWiki默认不会为匿名用户生成组权限记录，若存在将匿名用户加入无read权限组的残留数据，会直接触发API权限拦截
• 对比故障实例与正常实例的数据库表差异，重点核查两类配置：
  • 权限类扩展（如页面锁定类扩展）存储在数据库wikitext中的页面访问限制规则，是否存在将全局页面阅读权限设为仅登录用户可访问的配置（这类配置会导致前端缓存的公开页面可正常展示，但API请求实时校验时被拦截）
  • 动态站点设置扩展对应的配置表中，是否残留了关闭匿名API访问的旧配置

3. 排查Web层路径上下文错配 #

• 检查Web服务器（Nginx/Apache）对应wikiB站点的路由规则，确认/wikiB/api.php的请求确实指向wikiB实例的代码目录，无反向代理转发到其他站点API入口的错配
• 验证实例内$wgScriptPath、$wgArticlePath等路径配置的实际生效值，排除复制配置文件后未修改站点专属路径参数，导致MediaWiki在解析请求时错配到其他站点权限规则的问题

内容的提问来源于stack exchange，提问作者Regis May