我是 Asana 的开发者倡导者。如果我正确理解您的问题,那么是的,您必须为每个脚本分别处理回调。出于安全原因,我们验证 OAuth 应用程序注册注册的url 与身份验证时实际请求的集成相同。例如,如果这不是真的,则可以创建一个恶意脚本,该脚本使用client_id
来自合法脚本的 ,但要求重定向到它自己的凭据获取端点。如果获得应用client_id
程序注册的应用程序还精确指定了哪个端点应该是要重定向到的合法端点,则此问题已修复。这意味着每个 OAuth 应用程序都需要有自己独特且一致的重定向 URL :(
我想您可能会创建一个“路由器”Google Apps 脚本,该脚本会在访问 Asana 的oauth_authorize 端点state
时使用某些用户/脚本对设置参数,并将用户凭据转发到基于该用户的路由器脚本后面存在的脚本/响应返回时的脚本对,但这并不是非常简单的。
最后一种选择是使用个人访问令牌访问 Asana 的 API。无限数量的脚本可以使用这个令牌进行访问。缺点是这个令牌“看起来像你”,也就是说,它不是代表第三方用户而是代表你自己采取行动 - 你的脚本将是他们使用其个人访问令牌的用户的自动版本。这可以通过创建一个“机器人帐户”来访问我们的 API 并在 Asana 内部访问您想要收集数据的项目或团队来在一定程度上缓解这种情况。这种方法的另一个缺点是,如果您撤销一个令牌,每个使用个人访问令牌的脚本都会中断,因此,如果这种情况是有意或无意发生的,您必须在每个脚本中更新个人访问令牌信息使用它的脚本。
希望这可以帮助您评估选项并选择其中一个选项最适合您的脚本。