Push notifications for logged In user

[danielemariani]

Talking about push subscriptions, I understand that they are per device, not per user. What if I want to push a private notification to a logged in user, but I don't know if the user is still logged on the device where he once generated the subscription?

Take this use case:

• A user logs into my website
• I (the website) prompt him if he wants to receive personal push notifications (let's say I could send him a push when another user sends him a private message)
• I get the subscription and save it on my db for that specific user.
• If another user sends him a private message, I show the notification to the user.

Everything works like a charm but after some time the user logs out, and another user logs in to the same website from the same exact device (the first user girlfriend, let's say). Now, if someone sends a private message to the first user, his girlfriend will see the notification (because she's on the same device, and the permission is of course per-device and does not take into account any "login" logic).

How could that edge case be handled? I wouldn't like to track user login sessions in my backend, also because the user could log in at the same time on multiple devices and I also wouldn't like to pair each subscription to a specific device.

Is it a use case considered by the push-api, or is the api suitable to send only "generic" notifications to all the users who gave their consent to display notifications?

[collimarco]

after some time the user logs out

Take a look at the Pushpad Javascript SDK: we manage that. See the uid option of unsubscribe in particular. Basically when the user logs out you can send a request to the application server like this: /remove_user_id?endpoint=.... When the server receives that request, it finds the endpoint in your database and removes any association to the user: in this way you will stop sending personal notifications to that endpoint. Also I recommend that you associate an endpoint at most to one user at a time: never associate an endpoint to multiple users at the same time because it doesn't make sense and it will become a nightmare (we did that in the past and we had to change).

[ghost]

As Collimarco said it’s possible if you catch the user logging out on your website (when they press the Logout button for example) But what about when the session expires naturally (ie they close the browser and reopen... that would delete php session cookies) or they delete cookies themselves and login as another user? There is no call to the server to delete the endpoint as it does with the logout button.

[collimarco]

@pete10 I agree with you that currently there is no way to properly manage the case of "session expiration" (maybe adding a new event sessionexpired to the service worker can solve that).

Currently the only workaround would be to add an expiration date to the user ID in your database: e.g. instead of having [endpoint, user_id] you can use [endpoint, user_id, uid_valid_through]. However the expiration date would be always different from the session expiration.

[beverloo]

This isn't a Push API issue. As others mentioned, be sure to unregister the Service Worker and/or push subscription when the user logs out. Your server could invalidate subscriptions when a user logs out. For client-side session expiration, take a look at the Cookie Store API that intends to provide a cookiechange event on the Service Worker global scope.

[stefanKP50]

Invalidate subscription on logout means "no way to send notifications and re-engage as long as user do not log in again". Right ? it destroys the interest of the sw, no ?