GitHub Enterprise Server 3.8下GraphQL API与UI/REST权限不一致问题咨询

你遇到的这个权限不一致问题确实挺让人费解的，我来帮你拆解下可能的情况和可行的应对思路：

现象确认 #

你作为非site-admin用户，目前能通过两种途径看到其他用户的封禁状态：

• GitHub Web界面的用户个人主页
• 调用GitHub REST API（使用的token权限是admin:org、repo、user:email）

但用同一token调用GraphQL API时，无论是通过search查询还是直接查询单个user，只要请求suspendedAt字段就会被提示需要site_admin权限，而你无法为token添加这个权限。

问题根源分析 #

这大概率是GitHub Enterprise Server 3.8版本里的权限逻辑不一致bug——GraphQL API的权限校验规则和UI/REST API没有对齐。从用户体验和系统权限一致性的角度来说，既然UI和REST都允许非site-admin查看用户封禁状态，GraphQL层理应遵循同样的规则，而不是额外要求更高权限。

当然也存在另一种小概率可能：UI/REST的权限设计其实是不符合规范的，非site-admin本不该看到封禁状态，但显然这个可能性更低，毕竟你已经实际能在界面和REST里获取到信息了。

针对你的需求的临时解决方案 #

既然你只关心用户是否被封禁，不需要具体的封禁时间suspendedAt，可以先采取以下方式绕过这个问题：

1. 暂时切换回REST API：既然REST API能正常返回封禁状态信息，先继续用它来满足你的需求，这是最直接的临时方案。
2. 向GitHub反馈问题：联系你们企业的GitHub管理员，或者直接提交GitHub支持工单，说明这个权限不一致的情况——明确告知他们非site-admin用户能在UI/REST查看封禁状态，但GraphQL API却要求site_admin权限，请求修复这个逻辑对齐问题。

额外提示 #

如果之后想尝试GraphQL的替代方案，你可以留意下是否有其他间接能判断用户封禁状态的字段（不过目前GHES 3.8的GraphQL schema里应该没有），所以暂时REST API是更稳妥的选择。

备注：内容来源于stack exchange，提问作者Markus Mitterauer