You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We only checked whether a stored push token (stored after registration) existed, not whether the stored push token was still valid.
Description
isPushNotificationsEnabled() checks for five different things:
Whether there is a stored OneSignal user ID
We don't make a request to OneSignal to verify this ID, since that can get expensive.
Whether there is a stored push token.
We don't check for the actual push subscription <---- This is the issue.
Whether the notification permission is granted.
This does a real check to the browser's Notification permission API.
Whether the user is manually opted out or not.
Users can be manually opted out using the setSubscription(false) method available on our SDK.
Whether a OneSignal service worker is active
A user who has a service worker from another push provider wouldn't pass the service worker check.
When checking whether there is a valid push token, we should check the actual token for HTTPS sites (e.g. serviceWorkerRegistration.pushManager.getSubscription()). This isn't possible for HTTP sites, since the service worker registration is inaccessible from within an insecure iFrame (top level origin is HTTP), but we can do this for HTTPS sites.
Application
Developers often re-test by clearing notification permissions to prompt themselves again. This causes them to be actually unsubscribed (in terms of the actual subscription, since resetting the permission sends a GCM unregistration event), but it doesn't remove the stored push token we have in IndexedDb that remembers their previous (now unsubscribed) push token.
When isPushNotificationsEnabled() is called, the user gets false until he grants his notification permission again. But the moment the user grants notification permissions, before the re-subscription actually completes (there are more steps involved) the code checked the stored (existing, but now invalid) push token to determine whether the push token existed, and did not check the actual push token to see whether the push token is still valid. This means the user would immediately get a subscriptionChange event of true, and our SDK would fire a welcome notification because of this. However, the user was actually still resubscribing, so the welcome notification would never arrive.
Note: We resubscribe the user anyways on new tab/window page loads so this wasn't a large-impact issue. It just helps people that resubscribe through partially clearing data.
Summary
We only checked whether a stored push token (stored after registration) existed, not whether the stored push token was still valid.
Description
isPushNotificationsEnabled()
checks for five different things:Whether there is a stored OneSignal user ID
We don't make a request to OneSignal to verify this ID, since that can get expensive.
Whether there is a stored push token.
We don't check for the actual push subscription <---- This is the issue.
Whether the notification permission is granted.
This does a real check to the browser's Notification permission API.
Whether the user is manually opted out or not.
Users can be manually opted out using the
setSubscription(false)
method available on our SDK.Whether a OneSignal service worker is active
A user who has a service worker from another push provider wouldn't pass the service worker check.
When checking whether there is a valid push token, we should check the actual token for HTTPS sites (e.g.
serviceWorkerRegistration.pushManager.getSubscription()
). This isn't possible for HTTP sites, since the service worker registration is inaccessible from within an insecure iFrame (top level origin is HTTP), but we can do this for HTTPS sites.Application
Developers often re-test by clearing notification permissions to prompt themselves again. This causes them to be actually unsubscribed (in terms of the actual subscription, since resetting the permission sends a GCM unregistration event), but it doesn't remove the stored push token we have in IndexedDb that remembers their previous (now unsubscribed) push token.
When
isPushNotificationsEnabled()
is called, the user getsfalse
until he grants his notification permission again. But the moment the user grants notification permissions, before the re-subscription actually completes (there are more steps involved) the code checked the stored (existing, but now invalid) push token to determine whether the push token existed, and did not check the actual push token to see whether the push token is still valid. This means the user would immediately get asubscriptionChange
event oftrue
, and our SDK would fire a welcome notification because of this. However, the user was actually still resubscribing, so the welcome notification would never arrive.This should also be related to #181.
The text was updated successfully, but these errors were encountered: