将3-legged OAuth的Forge Hubs浏览器改为2-legged OAuth时遇权限问题求助

一、「h scope is not allowed」错误解决 #

这个错误的核心原因是你沿用了3-legged OAuth的用户级scope，而2-legged（服务端身份）与3-legged（用户身份）的可用权限范围完全不兼容。

问题根源 #

3-legged OAuth使用的是绑定用户身份的scope（比如hubs:read、user-profile:read），但这类scope在2-legged模式下不被允许——2-legged仅支持应用级scope，权限基于你的APS应用在BIM 360账户中被赋予的角色。

修复步骤 #

1. 替换所有scope为2-legged支持的BIM 360相关权限：
   针对BIM 360 Docs浏览场景，仅需以下两个核心scope：
   • account:read：用于读取BIM 360账户（对应API中的Hub）信息
   • data:read：用于读取账户下的项目、文件夹、文档数据
2. 检查AuthClientTwoLegged初始化代码，确保传入的scope参数正确，示例：

   const { AuthClientTwoLegged } = require('forge-apis');
   const client = new AuthClientTwoLegged(
       process.env.FORGE_CLIENT_ID,
       process.env.FORGE_CLIENT_SECRET,
       ['account:read', 'data:read']
   );
   

3. 移除所有3-legged特有的scope（比如任何包含user-、hub:前缀的权限）

二、BIM 360账户ID与x-user-id的疑问 #

关于BIM 360账户ID #

• 2-legged OAuth默认可以访问所有已授权该应用的BIM 360账户。调用GET /hubs接口时，返回的BIM 360类型Hub的id字段就是账户ID。
• 如果你的应用需要限定访问特定账户，或者要直接调用某个账户下的项目/文档接口（比如GET /hubs/{hub_id}/projects），则必须指定该账户ID。

关于x-user-id请求头 #

• 不需要。x-user-id是3-legged OAuth中用于模拟特定用户操作的请求头，而2-legged OAuth是以应用身份发起请求，权限由应用在BIM 360账户中的角色（如文档管理员、服务管理员）决定，无需指定用户ID。

额外注意事项 #

• 确保你的APS应用已被添加到目标BIM 360账户中：需要BIM 360账户管理员在账户设置的「集成」页面添加应用，并分配合适的角色（至少需要「文档管理员」权限才能读取Docs内容）。
• 调整routes/hubs.js中的API逻辑：2-legged模式下调用GET /hubs返回的Hub列表仅包含已授权该应用的BIM 360账户，后续获取项目、文档的接口调用逻辑与3-legged一致，但无需处理用户授权回调。

内容的提问来源于stack exchange，提问作者Ayumu Oshiro