Change Details

= Background information Follow-up from T246716#6324971 = Questions we want to answer How should we handle cleaning up bad tokens in the database that are not removed by subscribers? = How will we go about answering the questions Review the approaches to this issue taken by pushd and other open-source push notification server projects. = Results **Projects reviewed:** [[ https://github.com/rs/pushd | pushd ]], [[ https://github.com/Nordeus/pushkin | pushkin ]], [[ https://github.com/uniqush/uniqush-push | uniqush ]], [[ https://github.com/signalapp/PushServer | Signal push server ]], [[ https://github.com/airnotifier/airnotifier | AirNotifier ]], [[ https://github.com/jdlrobson/web-push-subscriber | web-push-subscriber ]], [[ https://github.com/Nickersoft/push.js | push.js ]] It turns out that there is a strong consensus on this point: they simply delete subscriptions for which a bad-subscription response is received, as soon as it is received. The only exceptions are pushkin, which marks them as unregistered and deletes them later (apparently when the number of subscriptions grows too large); Signal push server, which pushes them on an unregistered device queue, but doesn't appear to do anything with that queue; and push.js, which has no provision for cleaning up bad subscriptions. The pushd documentation states that apps are expected to ping the push service each time they are launched to ensure they are subscribed, and (re-)subscribe if not. (Its README file describes this as "letting pushd know the subscriber still exists," but that doesn't quite accurately describe what the code is actually doing.) I think that's a good approach for our apps to take as well. The only somewhat tricky bit that we have to deal with and these existing projects don't is that we don't have direct access to the subscriber database, and instead have to work across a service boundary and ask MediaWiki to delete subscriptions on behalf of the service. I think we can deal with this in the following way: * In Echo, create a new user right (something like `manage-all-push-subscriptions`) and a new group (e.g., `push-subscripton-managers`) with that right * Update ApiEchoPushSubscriptionsDelete to allow users with the `manage-all-push-subscriptions` right to delete any token from the push subscriptions table * Choose a wiki through which the push-notifications service will communicate back with Wikimedia's MediaWiki installation (suggestion: metawiki) * On that wiki, create a bot account for the push-notifications service and add it to the newly created `push-subscription-managers` user group * Update the push service to be able to authenticate to MediaWiki and send push subscription delete requests * Update the APNS and FCM response handlers to identify bad subscriptions/tokens and send subscription delete requests to the designated wiki for those tokens

= Background information Follow-up from T246716#6324971 = Questions we want to answer How should we handle cleaning up bad tokens in the database that are not removed by subscribers? = How will we go about answering the questions Review the approaches to this issue taken by pushd and other open-source push notification server projects. = Results **Projects reviewed:** [[ https://github.com/rs/pushd | pushd ]], [[ https://github.com/Nordeus/pushkin | pushkin ]], [[ https://github.com/uniqush/uniqush-push | uniqush ]], [[ https://github.com/signalapp/PushServer | Signal push server ]], [[ https://github.com/airnotifier/airnotifier | AirNotifier ]], [[ https://github.com/jdlrobson/web-push-subscriber | web-push-subscriber ]], [[ https://github.com/Nickersoft/push.js | push.js ]] It turns out that there is a strong consensus on this point: they simply delete subscriptions for which a bad-subscription response is received, as soon as it is received. The only exceptions are pushkin, which marks them as unregistered and deletes them later (apparently when the number of subscriptions grows too large); Signal push server, which pushes them onto an unregistered device queue, but doesn't appear to do anything with that queue; and push.js, which has no provision for cleaning up bad subscriptions. The pushd documentation states that apps are expected to ping the push service each time they are launched to ensure they are subscribed, and (re-)subscribe if not. (Its README file describes this as "letting pushd know the subscriber still exists," but that doesn't quite accurately describe what the code is actually doing.) I think that's a good approach for our apps to take as well. The only somewhat tricky bit that we have to deal with and these existing projects don't is that we don't have direct access to the subscriber database, and instead have to work across a service boundary and ask MediaWiki to delete subscriptions on behalf of the service. I think we can deal with this in the following way: * In Echo, create a new user right (something like `manage-all-push-subscriptions`) and a new group (e.g., `push-subscripton-managers`) with that right * Update ApiEchoPushSubscriptionsDelete to allow users with the `manage-all-push-subscriptions` right to delete any token from the push subscriptions table * Choose a wiki through which the push-notifications service will communicate back with Wikimedia's MediaWiki installation (suggestion: metawiki) * On that wiki, create a bot account for the push-notifications service and add it to the newly created `push-subscription-managers` user group * Update the push service to be able to authenticate to MediaWiki and send push subscription delete requests * Update the APNS and FCM response handlers to identify bad subscriptions/tokens and send subscription delete requests to the designated wiki for those tokens

= Background information Follow-up from T246716#6324971 = Questions we want to answer How should we handle cleaning up bad tokens in the database that are not removed by subscribers? = How will we go about answering the questions Review the approaches to this issue taken by pushd and other open-source push notification server projects. = Results **Projects reviewed:** [[ https://github.com/rs/pushd | pushd ]], [[ https://github.com/Nordeus/pushkin | pushkin ]], [[ https://github.com/uniqush/uniqush-push | uniqush ]], [[ https://github.com/signalapp/PushServer | Signal push server ]], [[ https://github.com/airnotifier/airnotifier | AirNotifier ]], [[ https://github.com/jdlrobson/web-push-subscriber | web-push-subscriber ]], [[ https://github.com/Nickersoft/push.js | push.js ]] It turns out that there is a strong consensus on this point: they simply delete subscriptions for which a bad-subscription response is received, as soon as it is received. The only exceptions are pushkin, which marks them as unregistered and deletes them later (apparently when the number of subscriptions grows too large); Signal push server, which pushes them onto an unregistered device queue, but doesn't appear to do anything with that queue; and push.js, which has no provision for cleaning up bad subscriptions. The pushd documentation states that apps are expected to ping the push service each time they are launched to ensure they are subscribed, and (re-)subscribe if not. (Its README file describes this as "letting pushd know the subscriber still exists," but that doesn't quite accurately describe what the code is actually doing.) I think that's a good approach for our apps to take as well. The only somewhat tricky bit that we have to deal with and these existing projects don't is that we don't have direct access to the subscriber database, and instead have to work across a service boundary and ask MediaWiki to delete subscriptions on behalf of the service. I think we can deal with this in the following way: * In Echo, create a new user right (something like `manage-all-push-subscriptions`) and a new group (e.g., `push-subscripton-managers`) with that right * Update ApiEchoPushSubscriptionsDelete to allow users with the `manage-all-push-subscriptions` right to delete any token from the push subscriptions table * Choose a wiki through which the push-notifications service will communicate back with Wikimedia's MediaWiki installation (suggestion: metawiki) * On that wiki, create a bot account for the push-notifications service and add it to the newly created `push-subscription-managers` user group * Update the push service to be able to authenticate to MediaWiki and send push subscription delete requests * Update the APNS and FCM response handlers to identify bad subscriptions/tokens and send subscription delete requests to the designated wiki for those tokens