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

Fire pushsubscriptionchange when user revokes permission #116

Closed
johnmellor opened this Issue Feb 24, 2015 · 12 comments

Comments

Projects
None yet
7 participants
@johnmellor
Contributor

johnmellor commented Feb 24, 2015

The spec says, "When a permission is revoked, all push subscriptions created with that permission must be deactivated" (i.e. automatically unsubscribed).

We should clarify in the pushsubscriptionchange section that the pushsubscriptionchange event must be fired in such cases.

This is different from #61 since the webapp's state (cookies, IDB, etc) haven't been reset, and so if we didn't fire pushsubscriptionchange, this would create a new state that sites have to explicitly handle.

(unlike other pushsubscriptionchange events, it won't be possible to resubscribe automatically - but that's fine, because sites already have to handle failure to resubscribe, e.g. in case the device is offline).

@gauntface

This comment has been minimized.

gauntface commented Feb 24, 2015

+1 this proposal - it would be a particularly nice UI for developers to handle renewing or maintaining their user account in the pushsubscriptionchange event listener.

@martinthomson

This comment has been minimized.

Member

martinthomson commented May 21, 2015

What ever happened to pushregistrationlost ? That seems like a more appropriate event. Or do we now consider pushsubscriptionchange OK if we subsequently return null to a call to getSubscription()?

@nikhilm

This comment has been minimized.

nikhilm commented May 27, 2015

getSubscription() should probably reject with PermissionDeniedError.

@kitcambridge

This comment has been minimized.

kitcambridge commented Jan 25, 2016

To clarify, this means we should fire pushsubscriptionchange twice, right? Once when permission is revoked, and a second time when it's restored.

So, after revocation, self.pushManager.getSubscription() will resolve to null (per @martinthomson's comment in #150), and subscribe() will reject with PermissionDeniedError. Is that accurate?

Also, if the user restores permission, should the browser automatically resubscribe, or leave it up to the service worker? (Firefox currently leaves it up to the worker, but it might be nice to be explicit about the correct behavior).

Thanks!

@martinthomson

This comment has been minimized.

Member

martinthomson commented Jan 26, 2016

I think that since we do have the permission API, the simplest (and least-surprising) option would be to have the page check and re-subscribe if the permission is re-granted.

@collimarco

This comment has been minimized.

collimarco commented May 24, 2016

+1 For triggering a callback when subscription is revoked by the user

This would allow the server to know that a user (for example a user id associated to that endpoint) is no more reachable with push notifications before trying to send them. This allows better handling for providing fallbacks methods (e.g. email). Beside that it allows to determine when a user has unsubscribed and do some analytics. I wrote more extensively about this topic in this blog post.

@kitcambridge

This comment has been minimized.

kitcambridge commented May 24, 2016

+1 For triggering a callback when subscription is revoked by the user

I see your point. Firefox only fires pushsubscriptionchange when permission is restored, because the service worker can't resubscribe if permission is revoked...so it didn't really make sense to notify the worker if it couldn't do anything about it.

As you point out, though, the worker can use the event to preemptively remove the old subscription endpoint from its app server, or for analytics.

Your app server will still need to handle the case where the push server drops a subscription without notifying the worker, though. This can happen if the browser isn't connected when the subscription is dropped. The worker will get a pushsubscriptionchange event when the browser is relaunched, but your server will get a 404 if it tries to send a message before then.

@collimarco

This comment has been minimized.

collimarco commented May 25, 2016

@kitcambridge You've got the point.
If the server has to manage that scenario as an exception is not a problem. However it's an exception, not the normal flow: statistically it would be a great improvement. Moreover I think that most of the time when a user unsubscribes has the browser open and probably is not offline.

However I'm not convinced by the sequence you have described: you say that the token has expired and the push service returns 404 to the application server. That's not possible if the browser is offline. If the user unsubscribes when he's offline neither the push service nor the app server can be informed: they'll be informed at the same time when the user connects to the internet. So I think that you'll never get 404 from the push service for this scenario.

@kitcambridge

This comment has been minimized.

kitcambridge commented May 25, 2016

Indeed; the user can't unsubscribe if the browser is closed.

The case I'm talking about is when the push server drops the subscription, without a request from the browser. The server can do this for any reason, at any time: for example, if there are too many outstanding messages for that subscription, if the browser hasn't reconnected in a while, or if the server is running into storage limits.

In that case, the browser will fire a pushsubscriptionchange event the next time it reconnects to the push server. But, until then, sending messages to the dropped subscription will return a 404.

@collimarco

This comment has been minimized.

collimarco commented May 25, 2016

@kitcambridge Thank you for the clear explanation! Yes, in that case you'll have to manage the 404 as an exception. We are saying the same thing. Indeed in the previous message I've written "you'll never get 404 from the push service for this scenario".

@kitcambridge

This comment has been minimized.

kitcambridge commented May 27, 2016

@collimarco You're right. I just misunderstood your first reply. 😄

@beverloo

This comment has been minimized.

Member

beverloo commented Feb 17, 2017

Following PR #234, it's now defined that user agents MAY fire the pushsubscriptionchange event when permission is revoked.

Whether we should fire the event when permission is regranted is tracked in #236. I'm still not convinced that should happen in all scenarios.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment