autonomic-cooperative/djangoldp-webpushnotification
Archived
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Finish accept subscriptions logic #2

New Issue
Closed
opened 2021-04-07 14:59:17 +00:00 by decentral1se · 4 comments
decentral1se commented 2021-04-07 14:59:17 +00:00
Owner
Copy Link

Accept subscriptions

We propose integrating django-webpush, which exposes the webpush/save_information endpoint, into djangoldp_notification. This is the endpoint that will receive requests from Hubl with the subscription requests for a user. Once Hubl has the correct VAPID keypair public key part, django-webpush will authenticate the client via the local VAPID keypair private key part and subscribe the user's browser to notifications about their account. We will unit test to validate these assumptions.

Ripped from https://git.startinblox.com/djangoldp-packages/djangoldp/issues/338.

> Accept subscriptions > > We propose integrating django-webpush, which exposes the webpush/save_information endpoint, into djangoldp_notification. This is the endpoint that will receive requests from Hubl with the subscription requests for a user. Once Hubl has the correct VAPID keypair public key part, django-webpush will authenticate the client via the local VAPID keypair private key part and subscribe the user's browser to notifications about their account. We will unit test to validate these assumptions. Ripped from https://git.startinblox.com/djangoldp-packages/djangoldp/issues/338.
decentral1se commented 2021-04-15 09:55:48 +00:00
Author
Owner
Copy Link

OK, wait a second, there are 3 things at play here:

image

(from https://blog.mozilla.org/services/2016/08/23/sending-vapid-identified-webpush-notifications-via-mozillas-push-service/)

In our case, I've just realised, we're making the back-end (djangoldp) both the "application server" and the "push server". This kind of unfucks the confusing-ness of when reading about web push architecture!

In the typical web push architecture, the "push server" has to trust the "application server" and deal with this intermediate step and some sort of token passing. We're skipping all of that!

OK, wait a second, there are 3 things at play here: - the "app": the front-end (hubl) - the "application server": the back-end (djangoldp) - the "push server": an intermediate step (like https://web-push-codelab.glitch.me/) ![image](/attachments/b4ecefb0-6879-4733-a38a-72561b1e035d) (from https://blog.mozilla.org/services/2016/08/23/sending-vapid-identified-webpush-notifications-via-mozillas-push-service/) In our case, I've just realised, we're making the back-end (djangoldp) both the "application server" and the "push server". This kind of unfucks the confusing-ness of when reading about web push architecture! In the typical web push architecture, the "push server" has to trust the "application server" and deal with this intermediate step and some sort of token passing. We're skipping all of that!
image.png
81 KiB
decentral1se commented 2021-04-15 11:06:00 +00:00
Author
Owner
Copy Link

So, the payload in our test (

djangoldp_webpushnotification/tests/tests_accept_subscription.py Line 25 in aaf365dba2
"keys": {"auth": "barfoo", "p256dh": "foobar"},
) is documented here:

https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription/getKey#parameters

The p256dh is the VAPID key public key!

To clarify the role of the auth key, it appears to be a thing which is generated by the front-end (Hubl) and then passed through the back-end (djangoldp) to encrypt the push notification messages that get sent back (see here).

I think we just need to add one additonal logic step to our registration step - we check that the value of the incoming p256dh in our test, matches up with a VAPIDKeySet public key value that we have stored in our back-end database.

So, the payload in our test (https://git.autonomic.zone/autonomic-cooperative/djangoldp-webpushnotification/src/commit/aaf365dba27b6ed63384d054dce9f10e20a90ad3/djangoldp_webpushnotification/tests/tests_accept_subscription.py#L25) is documented here: > https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription/getKey#parameters The `p256dh` is the VAPID key public key! To clarify the role of the `auth` key, it appears to be a thing which is generated by the front-end (Hubl) and then passed through the back-end (djangoldp) to encrypt the push notification messages that get sent back (see [here](https://github.com/web-push-libs/pywebpush/blob/a2dbc6f0f1fce632652ca6ea7654eabb5544cc9a/pywebpush/__init__.py#L213)). I think we just need to add one additonal logic step to our registration step - we check that the value of the incoming `p256dh` in our test, matches up with a `VAPIDKeySet` public key value that we have stored in our back-end database.
decentral1se commented 2021-04-15 13:53:48 +00:00
Author
Owner
Copy Link

Done for now.

Done for now.
3wordchant commented 2021-04-15 16:31:12 +00:00
Owner
Copy Link

In our case, I've just realised, we're making the back-end (djangoldp) both the "application server" and the "push server".

Re-reading that Mozilla post (which I just wasted time finding independently, I should have come here first 🙈), I'm not sure this is the case. Quoth the page:

Push server: The server that handles the events and delivers them to the correct Subscriber. Each browser vendor has their own Push Server to handle subscription management. For instance, Mozilla uses autopush.

So I'm not sure it's incorrect that the code is hitting a mozilla.org URL -- at least in Firefox. Less clear about Chrome, which I think @trav was testing in.

> In our case, I've just realised, we're making the back-end (djangoldp) both the "application server" and the "push server". Re-reading that Mozilla post (which I just wasted time finding independently, I should have come here first 🙈), I'm not sure this is the case. Quoth the page: > **Push server**: The server that handles the events and delivers them to the correct Subscriber. Each browser vendor has their own Push Server to handle subscription management. For instance, Mozilla uses [autopush](https://github.com/mozilla-services/autopush). So I'm not sure it's incorrect that the code is hitting a `mozilla.org` URL -- at least in Firefox. Less clear about Chrome, which I think @trav was testing in.
👀 1
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: autonomic-cooperative/djangoldp-webpushnotification#2
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?