Jawbone UP API oAuth和访问令牌

Jawbone UP API oAuth和访问令牌,api,authentication,oauth,jawbone,Api,Authentication,Oauth,Jawbone,今天我开始深入研究Jawbone的UP API,在整个身份验证过程中,一切似乎都进展顺利。问题是,一旦我得到一个访问令牌,它总是同一个令牌,在我的任何请求中都不起作用,并且我不能用refresh\u令牌端点来更改它 oAuth设置: $url_params = array( 'response_type' => 'code', 'client_id' => CLIENT_ID, 'scope' => array('basic_read', 'extend

今天我开始深入研究Jawbone的UP API,在整个身份验证过程中,一切似乎都进展顺利。问题是,一旦我得到一个访问令牌,它总是同一个令牌,在我的任何请求中都不起作用,并且我不能用refresh\u令牌端点来更改它

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,我被发送到颌骨,并按预期提示。当我接受授权时,我会像预期的那样被踢回my-site.com,URL中有代码。然后我像这样使用代码

$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\u 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\u令牌
和正确的API调用成功刷新,令牌也不会更改-调用成功,但Jawbone会返回相同的令牌。如果我通过jawboneapi控制台测试相同的流,那么请求头中的承载令牌与我在这里得到的不同。请注意,当我尝试使用我妻子的颌骨凭据执行相同的过程时,我也会获得相同的访问令牌。

最终了解了发生了什么,并从颌骨那里听到了相关消息。如果对两个不同的客户端使用相同的身份验证,那么它们在后端会发生冲突

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

在我们的例子中,我们有测试用户帐户,这些帐户通常在开发人员之间共享,因为有时很难获得真实的数据,除非您拥有实际的设备。这导致了“重复”登录,使颌骨代码崩溃


我们得到了一位颌骨开发人员的确认,他在开发内部应用程序时遇到了同样的问题。…

你有没有发现这个问题?这很奇怪-我有一个类似的问题…不幸的是没有什么,这阻碍了我的发展。这真的很糟糕,但在这一点上我完全被难住了。然而,我确实因为这个问题赢得了风滚草徽章,所以我已经做到了,这很好。代理或缓存问题?尝试添加所有可用的作用域。我的问题在那之后就解决了。谢谢你回答这个非常非常古老的话题。我早就不再玩弄Jawbone API了,但我很高兴有了一些解决方案。如果我有时间再谈,我会记住的。