Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebPush support #1225

Open
karmanyaahm opened this issue Jun 18, 2022 · 21 comments
Open

WebPush support #1225

karmanyaahm opened this issue Jun 18, 2022 · 21 comments

Comments

@karmanyaahm
Copy link
Contributor

Support for pushing to WebPush compatible servers would be very useful. It would allow pushing to the web app even when the tab is closed, and to the F-Droid version of Nextcloud Android using UnifiedPush.

Implementation

The primary things that need to be changed are:

  1. Create a v3 API endpoint to register devices with WebPush style keys
  2. Change the encrypt function to handle the WebPush keys in case the device is v3
  3. Minor changes to headers on sending the push request

Advantages

Can push to Web and open source Android apps (using a fully self-hosted notification stack) through existing push channels (no need to keep a new connection open).

Previous relevant discussions

This repo is the first step before such a feature could be used in apps. See nextcloud/talk-android#257 nextcloud/android#8684

#1054 mentioned https://github.com/nextcloud/notify_push as a solution, however, it doesn't solve the problem of receiving notifications when either the web app is not open, or on Android without a persistent connection.


Would you be interested in receiving a PR for such a feature?

@samuraikid0
Copy link

Implement it

https://unifiedpush.org/developers/android/

@Zocker1999NET
Copy link

@maintainers: I'm currently implementing UnifiedPush support to the notification backend / this app to then enable the Android app to use it.

I have a technical question regarding the database handling (as I target for the implementation to be merged into master): Should I try to reuse the current table notifications_pushhash table to store the UP information (distributor URI) or can I create a separate table to handle that data?
The second way seems cleaner to me but I can think of some reasons to re-use the current existing table (e.g. so one app cannot register for both normal & unified push), hence the question.

@nickvergessen
Copy link
Member

If the current table structure works it would be totally fine too reuse it.
If you need more or different columns to store different data you could use a different one. The proxy column can be the distributor uri, that's exactly how we do it as well.

so one app cannot register for both normal & unified push

I guess this is very unlikely to happen or to be needed.

But i leave this up to you

@karmanyaahm
Copy link
Contributor Author

karmanyaahm commented Jan 16, 2023

For context,
Right now, nextcloud-specific columns are:
1 - id
2 - uid
3 - token
4 - deviceidentifier
9 - apptype

push-v2 specific columns are:
5 - devicepublickey
6 - devicepublickeyhash
7 - pushtokenhash
8 - proxyserver

WebPush only needs

Public Key = 5
Auth Token ~= 7
endpoint = 8
And a way to identify it is WebPush not push-v2.

@nickvergessen
Copy link
Member

Is the UnifiedPush then hosted by the Nextcloud Server operator, the mobile app developer or the end user?

@provokateurin
Copy link
Member

Usually by none of those groups, although some people self-host. Take ntfy.sh for example, someone runs it and anyone can use it, but you can also choose to host your own ntfy server. Also there is no "the Unified Push", it's just a set of standards and protocols and can be implemented independently of any other component of the whole push system. See the animated chart at https://unifiedpush.org

@provokateurin
Copy link
Member

provokateurin commented Jan 16, 2023

There is also https://apps.nextcloud.com/apps/uppush which can serve as a provider if the users chooses so. Once Nextcloud has native WebPush support it will be possible to completely self-host notifications without any 3rd party in between, because everything is done using Nextcloud.

@nickvergessen
Copy link
Member

Okay, the auth token is enough to verify that someone is allowed to push to something? There is no additional origin confirmation of any sorts?
Just thinking about potential abuse scenarios which we would like to prevent.

@provokateurin
Copy link
Member

Yes, I think the biggest problem will be SSRF because the server will have push to any endpoint the device registers with.

@provokateurin
Copy link
Member

Btw another cool feature that could be implemented after having WebPush would be push notifications for browsers even when all the tabs are closed :)

@karmanyaahm
Copy link
Contributor Author

There is no additional origin confirmation of any sorts?

In WebPush (RFC8030, from which UnifiedPush derives key principles), the endpoint, the URL the notifications are pushed to is a capability URL. The endpoint might be https://ntfy.sh/upRANDOM98765432?up=1. That URL serves as a password for who is allowed to push to a UnifiedPush/WebPush endpoint.

The public key and auth token are separate, defined by RFC8291 for encryption of the payload.

TL;DR RFC8030 or the UnifiedPush spec is for sending stuff, RFC8291 is for encrypting that stuff

@karmanyaahm
Copy link
Contributor Author

In addition, if you want to push to Chrome (neither UnifiedPush nor Firefox require this), you need VAPID (RFC8292), but that is a per-server key not per-user, so it's trivial to add on after the fact.

@provokateurin
Copy link
Member

@Zocker1999NET any progress on your implementation?

@Zocker1999NET
Copy link

Sorry, I'm currently a little bit overwhelmed by life stuff (especially my studies).

But to the progress: I've mostly worked on rewriting the current code to easily support multiple notifications as the current implementation is heavily specialized for routing notifications through Nextcloud's Push Proxy for GCM/APNS (e.g. by batching notifications, triming content, …). That should/may be finished after an additonal 6 to 8 hours of work, I plan to then publish a PR for this refactoring.

Implementing UnifiedPush on this refactored code is then plain simple and nearly already done.

@githubkoma
Copy link

That should/may be finished after an additonal 6 to 8 hours of work, I plan to then publish a PR for this refactoring.

This sounds great, much more sophisticated than my proof of concept over at: https://github.com/githubkoma/webpush

@Zocker1999NET
Copy link

@githubkoma Probably it is as it should enable UP notifications for all Nextcloud notifications. However, your work & expertise might come in handy as I've no idea on how WebPush works. I hope I find time this week to at least publish my current progress so you (or anyone else) could start on implementing WebPush on top of that

@sobassy
Copy link

sobassy commented Jun 12, 2024

Sorry to bother you all.

Are there any updates on this?
Many people really want to get notification via PWA.

@p1gp1g
Copy link

p1gp1g commented Jul 31, 2024

@Zocker1999NET Any chance you can you share your work ? It would be useful if someone wants to continue it

Zocker1999NET added a commit to Zocker1999NET/nextcloud-notifications that referenced this issue Aug 1, 2024
- based of a commit from early 2023
- also I did not continued to work on this since then
- started as an approach to fix nextcloud#1225
- to all: feel free to extend this code, I hereby release my changes
  under the license in ./LICENSE (AGPL 3.0)
@Zocker1999NET
Copy link

Zocker1999NET commented Aug 1, 2024

Sorry that I discontinued my work on this (being another victim of RL coming up with more important stuff ^^)
@p1gp1g I'm not sure how helpful this might still be, as my work is still based of a commit from early 2023, namely 686cb5b.

But if someone wants to take a look, see: https://github.com/Zocker1999NET/nextcloud-notifications/tree/unified-push
I started to rewrite some parts to allow easier support of multiple notification methods by introducing common interfaces and by extracting common code for encryption/signing and so on.

@p1gp1g
Copy link

p1gp1g commented Aug 1, 2024

Thank you ! It will be useful if someone wants to continue it.

I think it would be more efficient, at least for the review, to split this PR in 2: The 1st to allow multiple pushers, and the 2nd to add webpush (based on the 1st)

@gavine99
Copy link

gavine99 commented Sep 5, 2024

I have submitted some pull requests that don't change architecture to achieve nextcloud notifications to be sent via the 3rd party unified push app. see;

... also a pull request for the 3rd party unified push app that can be applied after the pull requests above are applied; https://codeberg.org/NextPush/uppush/pulls/17

i have also submitted pr's for the generic (f-droid) android nextcloud client and talk apps to use the nextcloud server changes and these changes to create an end-to-end solution for unified push notifications and talk;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants