Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Web Push Notifications #3243
This PR introduces the ability to send Web Push Notifications. The basic idea is to save a push subscription to the backend, which can then be used to wake up the Service Worker and display a notification when something happened, even if Mastodon is not opened. Together with #3052 this can make Mastodon pretty much indistinguishable from a native application (at least on Android).
Features to implement:
Browser support: Chrome and Firefox. Cannot be polyfilled.
I have some questions and found something suspicious, so please review them. I'm looking forward this feature.
I still haven't figured out how to attach the subscription to the session, so that when the user logs out the subscription gets deleted. Also need to pass the VAPID keys via config files / environment (right now they are generated when the server starts).
@akihikodaki I explored a bit our options for clearing the subscriptions. We have the following in
# Reuse access token for the same resource owner within an application (disabled by default) # Rationale: https://github.com/doorkeeper-gem/doorkeeper/issues/383 reuse_access_token
What I understand from this is that we do not keep track of each user session (we use one token for all sessions), so there is no way to associate a push subscription with the session that created it. What is the reason for this? What would be the implications of issuing a new token for each login and deleting the token when the user logs out (attaching the push subscription to this token and deleting them together).
Another approach would be to manually delete the push subscription from the front-end when the user logs out, but that would create a huge security / privacy issue.
Don't really know how to proceed with this.
Result: the user is logged out, but the browser keeps getting push notifications for that account. Also someone can mess with the code and skip the request to delete the subscription.
Signing out and deleting the subscription should be an atomic operation, handled by the back-end.
Ideally, there would be another model (
Even now we have
This was referenced
Jun 6, 2017
I think this is ready for review. The service worker is configured not to cache anything. The
For testing, after you see the "Subscription registered" notification, go to the settings notifications and:
This will make it less confusing which type of notifications you are receiving. Would be nice if you could take a look at Chrome and Firefox on Android.
@sorin-davidoi it's hard to see how user-side logging is really going to help in this case (it's difficult enough to get users to tell us when something goes wrong, much less get them to have the dev console open at the right time) but if you think it's important to keep it, I defer to your judgement
ah, about the console log statements? i'm indifferent
for most users i don't think they be any use but on bleeding edge instances they may come in handy
maybe leave them in master for a bit and remove before the next tagged release? idk
another option is to leave them in here, then make another PR that removes them so that if anyone needs to enable them for testing all they need to do is revert the commit that removes them
I have added many comments, but they are trivial and the logic itself looks fine. I hope they will be addressed soon and the change will be merged.
All problems I have requested are addressed, but I found a few other suspicious things.
Seems to be addressed. There are some code style issues (from a human PoV, not code climate) that I intend to refactor in the future, but I think overall this is fine