This diff enables keyserver to send the WNS notifications to windows devices. The actual wnsSinglePush is implemented based on this official quickstart tutorial.
Details
Details
- Reviewers
kamil tomek - Commits
- rCOMMf02c679a3144: [keyserver] Send WNS notifications
Tested with the later diffs, with a Windows desktop client capable of accepting notifications. Send a notifications, test if it shows up on the windows machine. Check if the delivery appears in the notifications table in the db. Check if the device_token is removed if it's incorrect.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| keyserver/src/push/send.js | ||
|---|---|---|
| 959 ↗ | (On Diff #24565) | |
| keyserver/src/push/utils.js | ||
| 295–315 ↗ | (On Diff #24565) | We can slightly improve performance by awaiting a little bit later. This will work because first requests should resolve earlier and don't need to wait for the later ones. |
| 299–303 ↗ | (On Diff #24565) | Is there a length limit for WNS notification? |
| 312 ↗ | (On Diff #24565) | It might be beneficial for readability to say that these are notif ids. |
| 346 ↗ | (On Diff #24565) | Why do we send a request to deviceToken? |
Comment Actions
Improved error handling and added checking the domain of the url.
| keyserver/src/push/utils.js | ||
|---|---|---|
| 299–303 ↗ | (On Diff #24565) | According to these docs the length limit is 5000 bytes. I've added a warning when we exceed it (this is how we handle notifications for other providers). |
| 346 ↗ | (On Diff #24565) | The Windows API returns a URL that we should send notifications to. According to the docs
Channel URI is the URL returned by the API and stored by the client in the device_token. Also according to these docs:
So I've added that check |
| keyserver/src/push/utils.js | ||
|---|---|---|
| 293–295 | These are urls containing tokens, so maybe we should rename them? | |