【问题标题】:Asana API Personal Access Token return 401 (Unauthorized)Asana API 个人访问令牌返回 401(未经授权)
【发布时间】:2017-06-11 16:07:36
【问题描述】:

当我们访问 Asana API 时,我们将 Asana node client v0.15.0 与 Tampermonkey 脚本一起使用。 Api 正在响应 401(未经授权)

这几天前奏效了。我已尝试使用新的个人访问令牌,但仍然遇到相同的错误。 在摆弄请求时,我尝试将 auth-header Bearer 更改为小写。

Authorization: Bearer my-personal-access-token -> Authorization: bearer my-personal-access-token

这似乎工作正常,这表明 Asana 方面发生了一些变化。

node-asana js 客户端库不允许我在将请求发送到 Asana API 之前对其进行修改。

根据Asana API support,我应该在 stackoverflow 上寻求有关此问题的帮助。

编辑

通过进一步调查,似乎当我们发送 cookie 时 auth_token=My auth token 我们确实收到了 401 错误。但是如果删除 cookie 并在 fiddler 中重新发出请求,它就可以正常工作。

另一个注意事项是,现在我们在来自例如 https://app.asana.com/api/1.0/tasks/TaskId

的响应中没有得到任何 custom_fields

【问题讨论】:

    标签: asana asana-api


    【解决方案1】:

    我是 Asana 的开发者倡导者。您发现了一些已知问题,我们正在努力修复:) 我们正在推出a new version of our API。它旨在与旧实现向后兼容,但为我们提供多种形式的身份验证是我们在两者之间做不同事情的情况之一。

    出于安全考虑,我们最初在新版本中实现了这一点,不允许具有多种身份验证形式的请求,但事实证明,浏览器内集成的影响与您所看到的方式完全相同:登录到 Asana,这会导致您的浏览器自动向asana.com 发送请求的授权凭据,并且使用 OAuth 或个人访问令牌为我们的 API 授权“正确方式”最终会中断。我们正在努力解决这个问题,以便在登录(cookie)用户和 API(访问令牌)用户相同的情况下也能正常工作。

    如果这是一个紧急问题,并且您希望在我们在较新的 API 实现中推出修复程序时强制执行旧行为,您可以按照该链接中所述设置标头 --^ 以强制您的请求旧的 API。但是,一旦我们完全部署并稳定了新 API,我们将弃用该标头,因此请谨慎依赖它作为长期解决方案。

    很抱歉这给您带来了问题,感谢您提出这个问题让我们知道!

    【讨论】:

    • 感谢您的解释!我们做了一个解决方法,所以我们使用 OAuth2 而不是访问令牌,它对我们来说很好用。没有得到 custom_fileds 的问题似乎也得到了解决。
    猜你喜欢
    • 2017-07-06
    • 1970-01-01
    • 2016-12-24
    • 2018-09-05
    • 1970-01-01
    • 2023-03-09
    • 2019-11-02
    • 2016-05-17
    • 2014-01-30
    相关资源
    最近更新 更多