我不知道如何制作一个使用 OAuth 2.0 的 共享 Google Apps 脚本库。
问题是 usercallback 重定向 URL 更改，每次我在不同的脚本中使用库时。但是，这意味着我需要为我使用脚本的每个电子表格添加一个新的应用程序和白名单重定向 URL 到 Asana。我使用的是https://github.com/googlesamples/apps-script-oauth2。
有没有办法始终使用相同的重定向 URL 进行身份验证，以便可以从任何脚本中使用我制作的库，而无需在 Asana 中注册新的重定向 URL？
【问题讨论】：
标签： google-apps-script oauth oauth-2.0 asana-api asana-connect
我是 Asana 的开发者倡导者。如果我正确理解您的问题，那么是的，您必须为每个脚本分别处理回调。出于安全原因，我们验证 OAuth 应用注册是否将 same url 注册为身份验证时实际请求的集成。例如，如果这不是真的，则可以创建一个恶意脚本，该脚本使用合法脚本中的client_id，但要求重定向到它自己的凭据获取端点。如果在应用注册时获得client_id 的应用还精确指定了哪个端点应该是要重定向到的合法端点，则此问题已得到修复。这意味着每个 OAuth 应用程序都需要有自己唯一且一致的重定向 URL :(
我想您可能会创建一个“路由器”Google Apps 脚本，该脚本会在点击 Asana 的 oauth_authorize endpoint 时使用一些用户/脚本对设置 state 参数，并将用户凭据转发到存在于响应返回时基于该用户/脚本对的路由器脚本，但这并不是非常简单的。
最后一个选项是使用Personal Access Token 来访问 Asana 的 API。无限数量的脚本可以使用这个令牌进行访问。缺点是这个令牌“看起来像你”，也就是说，它不是代表第三方用户而是代表你自己采取行动 - 你的脚本将是他们使用个人访问令牌的用户的自动版本。这可以通过创建一个“机器人帐户”来访问我们的 API 并在 Asana 内部访问您想要收集数据的项目或团队来在一定程度上得到缓解。这种方法的另一个缺点是，如果您撤销一个令牌，每个使用个人访问令牌的脚本都会中断，因此，如果这种情况是有意或无意发生的，您必须在每个脚本中更新个人访问令牌信息使用它的脚本。
希望这可以帮助您评估选项并选择其中一个选项最适合您的脚本。
【讨论】：