Jawbone UP API oAuth 和访问令牌 [英] Jawbone UP API oAuth and Access Tokens
问题描述
我今天开始深入研究 Jawbone 的 UP API，在整个身份验证过程中似乎一切顺利.问题是，一旦我取回访问令牌，它总是相同的令牌，它在我的任何请求中都不起作用，而且我无法使用 refresh_token 端点更改它.
I have started digging into Jawbone's UP API today and everything seems to go fine throughout the authentication process. The problem is that, once I get an access token back, it's always the same token, it doesn't work in any of my requests, and I can't change it with the refresh_token endpoint.
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.然后我像这样使用代码
These are the parameters attached to the https://jawbone.com/auth/oauth2/auth URL and I get sent to Jawbone and prompted as expected. When I accept the authorization I get kicked back to my-site.com as expected with the code in the URL. I then use the code like so
$params = array(
'client_id' => CLIENT_ID,
'client_secret' => APP_SECRET,
'grant_type' => 'authorization_code',
'code' => $code,
);
并将这些参数附加到 https://jawbone.com/auth/oauth2/token 并最终被踢回我的服务器，类似于:
And attach those parameters to https://jawbone.com/auth/oauth2/token and finally get kicked back to my server with something similar to:
{
"access_token": "REALLY_LONG_STRING",
"token_type": "Bearer",
"expires_in": 31536000,
"refresh_token": "ANOTHER_REALLY_LONG_STRING"
}
当我使用 access_token 尝试获得这样的响应时
When I use access_token to try and get a response like this
$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，这是每次的响应:
from the API, this is the response every time:
{
"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.
The token never changes, even in a private browsing session, and even if I successfully refresh using the provided refresh_token and the proper API call - the call succeeds, but Jawbone gives me back the same token. If I test the same flow through the Jawbone API Console, the Bearer token in the request headers is different from the one I get here. Note that I get the same access_token when I attempt the same process with my wife's Jawbone credentials as well.
推荐答案
终于弄清楚发生了什么，并从 Jawbone 那里得到了反馈.事实证明，如果您对两个不同的客户端使用相同的身份验证，它们会在后端发生冲突.
Finally figured out what was going on and heard back from Jawbone about it. It turns out that they have collisions on the backend if you use the same auth with two different clients.
对于遇到此问题的其他任何人，不要同时在两个不同的上下文中使用相同的登录名，因为它会以奇怪的方式重置身份验证.
For anyone else that runs into this problem, don't use the same login in two different contexts simultaneously as it will reset auths in weird ways.
在我们的案例中，我们有测试用户帐户，这些帐户通常在开发人员之间共享，因为除非您拥有实际设备，否则有时很难获得真实数据.这导致了重复"登录，导致 Jawbone 代码异常.
In our case, we have test user accounts that are often shared between devs since it is sometimes hard to get real data unless you have the actual device. This was causing 'duplicate' logins that made Jawbone code freak out.
我们得到了 Jawbone 开发人员的确认，他在开发内部应用程序时遇到了同样的问题......
We got confirmation from a Jawbone dev who ran into the same problem when developing an internal app.....
这篇关于Jawbone UP API oAuth 和访问令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
