【问题标题】:Jawbone UP API oAuth and Access TokensJawbone UP API oAuth 和访问令牌
【发布时间】:2015-10-07 13:14:45
【问题描述】:

我今天已经开始深入研究 Jawbone 的 UP API,并且在整个身份验证过程中似乎一切正常。问题是,一旦我取回访问令牌,它始终是同一个令牌,它在我的任何请求中都不起作用,而且我无法使用 refresh_token 端点更改它。

oAuth 设置:

$url_params = array(
    'response_type' => 'code',
    'client_id' => CLIENT_ID,
    'scope' => array('basic_read', 'extended_read', 'move_read'),
    'redirect_uri' => 'https://my-site.com/up_auth.php',
);

这些是附加到https://jawbone.com/auth/oauth2/auth URL 的参数,我被发送到 Jawbone 并按预期提示。当我接受授权时,我会使用 URL 中的代码按预期返回 my-site.com。然后我像这样使用代码

$params = array(
    'client_id' => CLIENT_ID,
    'client_secret' => APP_SECRET,
    'grant_type' => 'authorization_code',
    'code' => $code,
);

并将这些参数附加到https://jawbone.com/auth/oauth2/token,最后被踢回我的服务器,类似于:

{
    "access_token": "REALLY_LONG_STRING",
    "token_type": "Bearer",
    "expires_in": 31536000,
    "refresh_token": "ANOTHER_REALLY_LONG_STRING"
}

当我使用access_token 尝试得到这样的响应时

$headers = array(
    'Host: my-site.rhcloud.com',
    'Connection: Keep-Alive',
    'Accept: application/json',
    "Authorization: Bearer {$_REQUEST['access_token']}",
);

$ch = curl_init('https://jawbone.com/nudge/api/v.1.1/users/@me/moves');
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$o = curl_exec($ch);
curl_close($ch);
var_dump($o);

来自 API,这是每次的响应:

{
    "meta": {
        "code": 401,
        "error_detail": "You must be logged in to perform that action",
        "error_type": "authentication_error",
        "message": "Unauthorized"
    },
    "data": {

    }
}

令牌永远不会改变,即使在私人浏览会话中,即使我使用提供的 refresh_token 和正确的 API 调用成功刷新 - 调用成功,但 Jawbone 将相同的令牌返回给我。如果我通过 Jawbone API 控制台测试相同的流程,请求标头中的 Bearer 令牌与我在这里得到的不同。请注意,当我使用我妻子的 Jawbone 凭据尝试相同的过程时,我也会得到相同的 access_token。

【问题讨论】:

  • 你有没有想过这个问题?这很奇怪 - 我也有类似的问题......
  • 不幸的是,什么都没有,这阻碍了我的发展。这是一个真正的无赖,但在这一点上,我完全被难住了。不过,我确实为这个问题赢得了 Tumbleweed 徽章,所以我已经完成了,这很好。
  • 代理或缓存问题?
  • 尝试添加所有可用的范围。之后我的问题就解决了。

标签: api authentication oauth jawbone


【解决方案1】:

终于弄清楚了发生了什么,并从 Jawbone 那里听到了关于它的消息。事实证明,如果您对两个不同的客户端使用相同的身份验证,它们会在后端发生冲突。

对于遇到此问题的其他任何人,不要同时在两个不同的上下文中使用相同的登录,因为它会以奇怪的方式重置身份验证。

在我们的案例中,我们有经常在开发者之间共享的测试用户帐户,因为有时除非您拥有实际设备,否则很难获得真实数据。这导致了让 Jawbone 代码崩溃的“重复”登录。

我们得到了 Jawbone 开发人员的确认,他在开发内部应用程序时遇到了同样的问题.....

【讨论】:

  • 感谢您回复这个非常非常古老的话题。我早就停止使用 Jawbone API,但我很高兴有一些解决方案。如果有一天我回到它,我会记住这一点。
猜你喜欢
  • 1970-01-01
  • 2016-10-29
  • 2015-04-01
  • 2019-07-23
  • 1970-01-01
  • 2021-01-10
  • 2011-09-19
  • 2021-09-13
  • 1970-01-01
相关资源
最近更新 更多