QuickBlox REST API 无法获取推送通知订阅列表
QuickBlox REST API unable to get push notification subscription list
我一直在使用 QuickBlox 向我们在 iOS 和 Android 上的应用程序发送推送通知。我正在使用 Marmalade C++ SDK 来开发应用程序。我在获取已登录用户的活动推送通知订阅时遇到问题。
我已从 QB 管理面板检查我正在使用的用户有活跃的推送通知订阅,但请求 GET api.quickblox.com/subscriptions.json
returns 404 未找到。
API 方法 Retrieve subscriptions 的文档指出没有需要随请求传递的参数。它唯一需要的信息是在 header 中传递的 QB-Token。令牌间接指定登录的用户,因此这就是它所需要的。
然而,该方法的描述是
Retrieve subscriptions for the device which is specified in the authorization token.
但这并不完全正确,因为无法知道哪个设备正在发出请求。我假设这意味着为用户检索订阅。
在我们的应用程序中,检索订阅请求是在用户登录后立即执行的。已确认登录成功,其他API方法正常
收到 404 后,我尝试 create a new subscription 为用户当前的设备。如果设备已经存在订阅,则 POST api.quickblox.com/subscriptions.json
returns 201 表示成功,但响应 body 只是 []
。如果设备之前没有订阅,请求 returns 201,但响应 body 包含创建订阅的信息。
我可以很好地创建和删除通知事件,并且它们可以很好地传送到设备。我的问题是我无法轻易确认设备是否有有效的订阅,而且我不知道该订阅的 ID 是什么,所以我可以在用户注销时删除它。
好的,我已经设法解决了这个问题,我也被文档弄糊涂了,它没有清楚地解释它的意思
Retrieve subscriptions for the device which is specified in the
authorization token.
由于本文档的措辞含糊,我在让用户注册订阅时也遇到了问题。
为了获得 Quickblox 的授权令牌(针对 session 或用户 session),您之前必须使用文档中描述的参数生成 HMAC SHA1 签名:
- application_id(API 应用程序标识符)
- auth_key(认证密钥)
- 时间戳(Unix 时间戳)
- 随机数(Unix 时间戳)
- 用户[登录]
- 用户[密码]
- 签名(HMAC SHA1,如下所述)
使用这些参数及其值,您应该创建了一个如下所示的字符串:
'application_id=22&auth_key=wJHd4cQSxpQGWx5&nonce=33432×tamp=1326966962&user[login]=test@test.com&user[password]=test123'
然后 HMAC SHA1 这个值,使用你的应用程序密码作为 HMAC 密码,来获取请求的签名,例如C#
using (HMACSHA1 hmac = new HMACSHA1(Encoding.ASCII.GetBytes(secret)))
{
hmac.Initialize();
byte[] buffer = Encoding.ASCII.GetBytes(value);
return BitConverter.ToString(hmac.ComputeHash(buffer)).Replace("-", "").ToLower();
}
获得此签名后,您可以向 Quickblox 发送请求以获取授权令牌,对于此示例,它是用户 session.
的令牌
您需要在请求的 body 中发送用于生成签名的所有参数,包括生成的签名,并将其 POST
发送到端点 /session.json
例如
POST
到 /session.json
{
"application_id":"2",
"auth_key":"DtF9cZPqTF8Wy9Q",
"timestamp":"1333630392",
"nonce":"1236221330",
"user":
{
login: "test@test.com",
password: "test123"
},
"signature":"eb0ec2d8c8184a3e62b41da2afb6e8d690577fa4"
}
你得到的响应应该有我们需要的用户 session 请求的授权令牌。
解决您的问题
正如您提到的,此令牌无法用于检索用户订阅,并且 return 未找到,尽管推送通知的订阅已经存在并链接到用户。
发生这种情况的原因是因为用户与设备有 1:M 关系,而 Quickblox 不会 return 所有订阅,只有与发出请求的特定设备相关的订阅,但你必须告诉它这个。
我们缺少的元素是将设备参数添加到授权令牌,这在文档中描述得非常糟糕,如果有的话。
为了使其正常工作,我们需要在授权请求中添加device[udid]
和device[platform]
。这可以识别用户以及他们用于 Quickblox 的特定设备。
为此,请执行与上述完全相同的操作,但 HMAC SHA1 的值现在应该如下所示
'application_id=22&auth_key=wJHd4cQSxpQGWx5&device[platform]=android&device[udid]=2374682h23780239j&nonce=33432×tamp=1326966962&user[login]=test@test.com&user[password]=test123'
请注意,如果您按不同的顺序放置密钥,您将收到 'unexpected signature' 错误,设备 [平台] 必须在 auth_key 之后等...
使用此字符串生成您的签名,然后使用与上述类似的请求发送它:
例如
POST
到 /session.json
{
"application_id":"2",
"auth_key":"DtF9cZPqTF8Wy9Q",
"timestamp":"1333630392",
"nonce":"1236221330",
"user":
{
login:"test@test.com",
password:"test123"
},
"device":
{
"platform":"android",
"udid":"2374682h23780239j"
}
"signature":"5t4d2d8c81848b6c4s41da2afb6e8d690889bc4"
}
您从 Quickblox 取回的令牌应在请求订阅时用作 QB-Token
header 值:
GET
/subscriptions.json
在提高门票和搜索互联网后,我偶然发现了这段代码并研究了一会儿,设法找到了这个解决方案。
Sourcecode for Blackberry PushAuth using Quickblox
我希望这能帮助其他遇到此问题的人,因为我认为 Aleksi Grön 已经在 2 个月后解决了这个问题。
我一直在使用 QuickBlox 向我们在 iOS 和 Android 上的应用程序发送推送通知。我正在使用 Marmalade C++ SDK 来开发应用程序。我在获取已登录用户的活动推送通知订阅时遇到问题。
我已从 QB 管理面板检查我正在使用的用户有活跃的推送通知订阅,但请求 GET api.quickblox.com/subscriptions.json
returns 404 未找到。
API 方法 Retrieve subscriptions 的文档指出没有需要随请求传递的参数。它唯一需要的信息是在 header 中传递的 QB-Token。令牌间接指定登录的用户,因此这就是它所需要的。
然而,该方法的描述是
Retrieve subscriptions for the device which is specified in the authorization token.
但这并不完全正确,因为无法知道哪个设备正在发出请求。我假设这意味着为用户检索订阅。
在我们的应用程序中,检索订阅请求是在用户登录后立即执行的。已确认登录成功,其他API方法正常
收到 404 后,我尝试 create a new subscription 为用户当前的设备。如果设备已经存在订阅,则 POST api.quickblox.com/subscriptions.json
returns 201 表示成功,但响应 body 只是 []
。如果设备之前没有订阅,请求 returns 201,但响应 body 包含创建订阅的信息。
我可以很好地创建和删除通知事件,并且它们可以很好地传送到设备。我的问题是我无法轻易确认设备是否有有效的订阅,而且我不知道该订阅的 ID 是什么,所以我可以在用户注销时删除它。
好的,我已经设法解决了这个问题,我也被文档弄糊涂了,它没有清楚地解释它的意思
Retrieve subscriptions for the device which is specified in the authorization token.
由于本文档的措辞含糊,我在让用户注册订阅时也遇到了问题。
为了获得 Quickblox 的授权令牌(针对 session 或用户 session),您之前必须使用文档中描述的参数生成 HMAC SHA1 签名:
- application_id(API 应用程序标识符)
- auth_key(认证密钥)
- 时间戳(Unix 时间戳)
- 随机数(Unix 时间戳)
- 用户[登录]
- 用户[密码]
- 签名(HMAC SHA1,如下所述)
使用这些参数及其值,您应该创建了一个如下所示的字符串:
'application_id=22&auth_key=wJHd4cQSxpQGWx5&nonce=33432×tamp=1326966962&user[login]=test@test.com&user[password]=test123'
然后 HMAC SHA1 这个值,使用你的应用程序密码作为 HMAC 密码,来获取请求的签名,例如C#
using (HMACSHA1 hmac = new HMACSHA1(Encoding.ASCII.GetBytes(secret)))
{
hmac.Initialize();
byte[] buffer = Encoding.ASCII.GetBytes(value);
return BitConverter.ToString(hmac.ComputeHash(buffer)).Replace("-", "").ToLower();
}
获得此签名后,您可以向 Quickblox 发送请求以获取授权令牌,对于此示例,它是用户 session.
的令牌您需要在请求的 body 中发送用于生成签名的所有参数,包括生成的签名,并将其 POST
发送到端点 /session.json
例如
POST
到 /session.json
{
"application_id":"2",
"auth_key":"DtF9cZPqTF8Wy9Q",
"timestamp":"1333630392",
"nonce":"1236221330",
"user":
{
login: "test@test.com",
password: "test123"
},
"signature":"eb0ec2d8c8184a3e62b41da2afb6e8d690577fa4"
}
你得到的响应应该有我们需要的用户 session 请求的授权令牌。
解决您的问题
正如您提到的,此令牌无法用于检索用户订阅,并且 return 未找到,尽管推送通知的订阅已经存在并链接到用户。
发生这种情况的原因是因为用户与设备有 1:M 关系,而 Quickblox 不会 return 所有订阅,只有与发出请求的特定设备相关的订阅,但你必须告诉它这个。
我们缺少的元素是将设备参数添加到授权令牌,这在文档中描述得非常糟糕,如果有的话。
为了使其正常工作,我们需要在授权请求中添加device[udid]
和device[platform]
。这可以识别用户以及他们用于 Quickblox 的特定设备。
为此,请执行与上述完全相同的操作,但 HMAC SHA1 的值现在应该如下所示
'application_id=22&auth_key=wJHd4cQSxpQGWx5&device[platform]=android&device[udid]=2374682h23780239j&nonce=33432×tamp=1326966962&user[login]=test@test.com&user[password]=test123'
请注意,如果您按不同的顺序放置密钥,您将收到 'unexpected signature' 错误,设备 [平台] 必须在 auth_key 之后等...
使用此字符串生成您的签名,然后使用与上述类似的请求发送它:
例如
POST
到 /session.json
{
"application_id":"2",
"auth_key":"DtF9cZPqTF8Wy9Q",
"timestamp":"1333630392",
"nonce":"1236221330",
"user":
{
login:"test@test.com",
password:"test123"
},
"device":
{
"platform":"android",
"udid":"2374682h23780239j"
}
"signature":"5t4d2d8c81848b6c4s41da2afb6e8d690889bc4"
}
您从 Quickblox 取回的令牌应在请求订阅时用作 QB-Token
header 值:
GET
/subscriptions.json
在提高门票和搜索互联网后,我偶然发现了这段代码并研究了一会儿,设法找到了这个解决方案。
Sourcecode for Blackberry PushAuth using Quickblox
我希望这能帮助其他遇到此问题的人,因为我认为 Aleksi Grön 已经在 2 个月后解决了这个问题。