Skip to content
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

pushManager.subscribe should replace applicationServerKey if different #291

Closed
collimarco opened this issue Feb 17, 2018 · 2 comments
Closed

Comments

@collimarco
Copy link

I have noticed that updating the applicationServerKey is not easy: you need to ask to the end user to unsubscribe and resubscribe to push notifications.

At Pushpad we have noticed that some developers actually need to change the applicationServerKey, for example because they are migrating from other push services or because they have mixed different applicationServerKey on the same domain. Basically, errors happen and in case you need to replace the applicationServerKey you need to ask to the end users to manually unsubscribe and then resubscribe. It would be much better if pushManager.subscribe could replace the subscription automatically in case the applicationServerKey provided is different from that associated to the existing subscription.

@ghost
Copy link

ghost commented Feb 17, 2018

Basically, errors happen and in case you need to replace the applicationServerKey you need to ask to the end users to manually unsubscribe and then resubscribe.

Hi @collimarco! I don't understand why you'd need to ask the user; could you please elaborate? Assuming they haven't revoked permission, you should be able to call getSubscription, compare keys, and unsubscribe and subscribe again on mismatch without a permission dialog popping up, no?

@beverloo
Copy link
Member

Yes, that is the case on all implementations I'm aware of.

Silently replacing any previous subscriptions feels risky to me - as the developer, you'd want to synchronize such a change with your server. Changing the applicationServerKey of a subscription is a deliberately decision, and providing some sort of upgrade path for existing subscriptions with that would be reasonable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants