What happens if ...?
Note that HTTP apps don't have this issue since all of its users are subscribed from origin. But for HTTPS sites:
Modify the service worker file to trigger a browser-based update check after 24 hours. As part of the modification, call importScripts() to a special script (to be written) that modifies the app ID in IndexedDB and registers user's existing push subscription to the new app ID.
Because the service worker file has been modified, the browser itself will update the service worker and run our new script, so this is guaranteed to be run eventually, especially if we send another push notification after 24 hours of this modification, since I think browsers also perform their SW update check on a push event.
The script will copy the push subscription details on to a new OneSignal app. It can also remove push subscription details from the existing OneSignal app to show progress and prevent the user from getting another duplicate notification.
Once the new OneSignal app has the push subscription, this is all that's needed to prevent the user from getting duplicate notifications! The push subscription was always valid, we just needed the subscription to live on a separate OneSignal app for each separate origin to prevent 3 separate valid subscriptions pointing to the same actual user from being sent a notification (when sending to all users).
The script must have the other app's OneSignal IDs hardcoded. Something like a "if you, the worker, is running on origin c.example.com, please resubscribe for push on this new app ID c". Hardcoding the information into the script is the only way to prevent another round trip from occurring to fetch new information.
If a user is no longer subscribed, after or on Chrome 55 we can re-subscribe in the SW using PushSubscriptionOptions without needing to fetch the manifest.json gcm_sender_id.
We currently ask clients to simply create new OneSignal apps for each origin and update the app ID for each origin's init script.
The difference between this shorter approach and the above longer approach is that the above approach should theoretically resubscribe all subscribers who have an active service worker.
This current approach ignores existing subscribers and expects active subscribers to eventually revisit the website.
The user's client-side IndexedDb data and push subscription will no longer exist, since the HTTPS site is a different origin. A new user entry will be created for the user, in the same OneSignal app, since there is no user with an existing subscription that matches the newly obtained subscription after the user subscribes.
The user can have previously subscribed to the original HTTP version of the site and then the new HTTPS version of the site, and will receive two notifications if notifications are sent out to all users.
The SDK no longer automatically unsubscribes or modifies IndexedDB data when an App ID is detected to be different from before. This behavior was dangerous, so it was removed.
Instead, for existing users, the user will receive a new user ID, since users are registered on every new session, and the registration now occurs on a different app ID, so OneSignal will create a new user ID since it isn't able to find a previous user with the provided registration token.
The user will keep the same registration token and the same push subscription. This means that for non-working subscriptions, it will not be fixed by creating a new app.
For upgrades from HTTP to HTTPS, the change of origin automatically wipes out all IndexedDB data and push subscription, so users upgrading from HTTP to HTTPS only need to use a new app ID.
Note: In a future SDK update, I think it'd be great if all data could be segmented by app ID, so that switching between app IDs gives users a fresh start (in line with what you'd expect by creating a new app) without erasing previous data tied to a different app ID. Currently, our IndexedDB database only stores one set of information regardless of the app ID.
Environment: Chrome 54.0.2840.87 (64-bit) on Mac OS X 10.11.6
Revision: c5ec6c5a12f2ed748bb08c1a8567b3c0df89dccd-refs/branch-heads/2840@{#805}
- Subscribe.
- Close the tab you subscribed on.
- Clear Cookies and other site and plugin data (Settings -> Privacy -> Clear Browsing Data...).
- Send yourself a notification.
- Observe delivery results are okay.
- Send yourself another notification.
- Observe delivery results mark you as unsubscribed.
No. It looks like the browser sends an unregistration message though:
Yes. Google immediately tells us the user is no longer subscribed. The browser's chrome://gcm-internals does not record any message received.
Note 1: It looks like clearing Cookies and other site and plugin data is the only setting necessary in clearing browser data to unsubscribe the user (all the other clearing options are unrelated).
Note 2: This method of clearing data also unregisters the service worker itself which means the entry in chrome://serviceworker-internals is missing.