Finish accept subscriptions logic #2

New Issue

2021-04-07T14:59:17Z

decentral1se commented

2021-04-07 14:59:17 +00:00

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

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/)

(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

So, the payload in our test (

		djangoldp-webpushnotification/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

Done for now.

decentral1se closed this issue

2021-04-15 13:53:48 +00:00

3wordchant commented

2021-04-15 16:31:12 +00:00

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.

2 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: autonomic-cooperative/djangoldp-webpushnotification#2