Use Case: Updating OS-integrated surfaces

[aarongustafson]

When it comes to Notifications (and, eventually, Widgets) that are orchestrated by a Service Worker, some of those surfaces will be predicated on authentication.

For instance, a direct message that shows up as a push notification should probably only be shown if that user remains logged in to the service that delivered it. So if, for example, a Twitter DM was delivered to me as a Push, but then I log out of the Twitter PWA, the Service Worker should be informed of the logout event in order to know it should remove that push notification from the system.

As we begin to figure out how PWAs participate in a host OS through Widgets, it becomes similarly important to tie auth to those surfaces as well. Our current explorations are built on the Notification management concept, so any work we do to enable Service Workers to be auth-aware will benefit Widgets as well.

In order to make this a reality, it feels like 2 things become necessary:

1. A means of communicating events related to authentication from host process to the Service Worker. This could be done by developers through postMessage() but we might also consider defining an event ("authchange"?) or set of events ("login" and "logout") that a Service Worker could listen for.
2. A means of tracking which surfaces (notifications, widgets) are auth-tied. This could certainly be done by developers on their own (and tracked in IndexedDB, for example) or it could be a flag we set on Notification and Widget objects ("requires_auth"?) so that a Service Worker could quickly iterate active Notifications, destroying ones that should not longer be seen, and Widgets to update them to prompt login before they can be used.

Anyway, would love y’all’s thoughts on this.

[johnwilander]

Thanks! This is an interesting area indeed. In my mind it expands to "auth-aware" in general where site-controlled, browser-controlled, and OS-controlled things can be gated on the auth state. That also means minimal data needs to be transferred (1 bit) instead of full user IDs.

[npdoty]

What's the advantage in having this signal provided as an API/event by the browser/os? I would think any individual site could handle its own logic for when a user logs out and passing on to a service worker when that changes.

[Sora2455]

If the user is logged out due to their session expiring while no pages are open to the website in question, the service worker can't tell that their session has ended. Even with the CookieStore API, if you have a session cookie and a session that lasts e.g. 30 minutes, and the user closes all pages without logging out, then once those 30 minutes are up they shouldn't receive messages intended for logged-in users.

(Or at least that's my use case).