【问题标题】:Slack's apps.connections.open returns "invalid_auth" when I send the token via request body当我通过请求正文发送令牌时,Slack 的 apps.connections.open 返回“invalid_auth”
【发布时间】:2021-09-30 18:30:09
【问题描述】:

我正在尝试从浏览器调用 Slack 的 API,所以我在 Chrome 的开发控制台中运行了以下命令,但出现错误:

await (await fetch("https://slack.com/api/apps.connections.open", {
        method: 'POST',
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded',
        },
        body: new URLSearchParams({'token': 'xapp-1-MYTOKEN'})
    })).json()
→ {ok: false, error: 'invalid_auth'}

我认为通过请求正文提供令牌应该没问题,因为documentation 是这样说的:

令牌应该作为 HTTP 授权标头传递,或者作为 POST 参数传递。

我错过了什么吗?


我尝试了等效的(我认为)cURL 命令并且结果相同。

$ curl -s --data-urlencode token@TOKEN https://slack.com/api/apps.connections.open | jq
{
  "ok": false,
  "error": "invalid_auth"
}

我确保我的令牌是正确的;当我通过 Authorization 标头发送令牌时,API 调用成功:

$ curl -s -X POST -H Authorization:\ Bearer\ $(<TOKEN) https://slack.com/api/apps.connections.open | jq .ok
true

请注意,在使用 Fetch API 时不能使用 Authorization 标头,因为 CORS 限制(access-control-allow-headers 标头不包含“Authorization”)。


我了解通常从浏览器调用 Slack API 来保持令牌的机密性不是一个好主意。

【问题讨论】:

标签: fetch authorization slack-api bearer-token


【解决方案1】:

我联系了 Slack 支持,得到了答复:他们的文档当前不正确,并且当您使用此 API 时,应始终将令牌作为 HTTP 授权标头传递。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-10-21
    • 1970-01-01
    • 2022-01-03
    • 2020-01-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-09-17
    相关资源
    最近更新 更多