Page MenuHomePhabricator

Implement notification types, creation and encryption for APNs notifications
ClosedPublic

Authored by marcin on Jun 13 2024, 9:05 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 22, 12:38 PM
Unknown Object (File)
Fri, Nov 15, 8:23 PM
Unknown Object (File)
Fri, Nov 15, 7:12 PM
Unknown Object (File)
Fri, Nov 15, 7:11 PM
Unknown Object (File)
Wed, Nov 13, 3:41 AM
Unknown Object (File)
Fri, Nov 1, 6:51 PM
Unknown Object (File)
Oct 13 2024, 8:43 PM
Unknown Object (File)
Oct 13 2024, 8:14 PM
Subscribers

Details

Summary

This differential implements our own types for APNs notifications as well as notif construction and encryption.

Test Plan

In order to test this code we need to hack the keyserver since in order to send APNs notif we need apn.Notification object anyway (it is required by node-apn lib). The steps are:

  1. Apply this patch: https://gist.github.com/marcinwasowicz/1af0a2958830fd9eb080e639779b1628. It makes the keyserver use our own types and new code to build the notification but before sending it creates custom apn.Notification object and overwrites its headers and compile methods to return data from our own notification.
  2. Test that APNs notifications, rescind and badge updates work for both iOS and macos
  3. Flow (unrelatedly).

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

lib/types/notif-types.js
235–254 ↗(On Diff #41292)

I'm skeptical of nested type spreads like this

Rebase and move apns logic to separate file and make types elegant

lib/push/apns-notif-creators.js
1 ↗(On Diff #41558)

Likely the only file that needs review here.

46 ↗(On Diff #41558)

The logic is copy pasted from the keyserver but using our custom types. All assignments and conditions match the keyserver logic. The only difference is that node-apn library hides from us what goes into headers what into aps and what into custom payload. In this file this is explicit.

  1. Could you address @ashoat comments about spreads?
  2. For Tunnelbroker, I will need 3 things: deviceID, headers because those are specified when building HTTP2 request to APNs, and payload - stringified notif, built on the client and only passed to APNs by Tunnelbroker without modification, wondering if we shouldn't design types to avoid spreading headers along with other notif props, but you can also do it before calling Tunnelbroker, this is up to you.
lib/push/crypto.js
93 ↗(On Diff #41563)

shouldn't this be SenderDeviceDescriptor?

114 ↗(On Diff #41563)

I think this is now APNsVisualNotification object

lib/types/notif-types.js
202 ↗(On Diff #41563)

that's not all types, see here. Do we want to add types to only what we support?

Regarding my comments about nested spreads – I still think they're ugly, but we looked into this with @marcin in a 1:1 and I think Flow is now able to support them better than I remembered previously

lib/types/notif-types.js
202 ↗(On Diff #41563)

I deliberately narrowed the type only for the headers that we currently use.

Update type name in the invariant. Rename cookieID to cryptoID

This revision is now accepted and ready to land.Jul 3 2024, 3:41 AM