What's this about?

The idea that Icinga Web displays notifications on the desktop is a very old one. What better reason to add/research that is it, that we are about to re-imagine how notifications in Icinga work?

Research?

We don't want to show only in-app notifications. Desktop notifications are to be preferred here, as they appear even if the browser tab is not focused. Though, we don't want to rely on a push service such as Google, due to privacy concerns. Thus we need to push the notifications on our own.

For this we need a service worker and our own persistent communication. Since this does not exist in Icinga Web until now, we first have to play with it to see how we'd like to integrate this into our framework.

The goal is to integrate this eventually into Icinga Web natively and Icinga Notifications is only a component relying on it. Though, until we chose a final implementation, Icinga Notifications is the sole playground. That way we are independent of the Icinga Web release cycle and have the freedom to make significant changes.

Related Technologies

• ServiceWorker API
• WebSocket API
• HTTP/2

Architecture

Browser ⇆ Webserver ⇆ Backend ⟶ Database ⟵ Notifications

The browser establishes a connection to our backend using the usual endpoint. The backend is a daemon written in PHP which runs continuously besides the web-server and polls the database.

The question here is, whether websockets or HTTP/2 should be used. Websockets seem to be fairly old already and HTTP/2 would save us some hassles I believe.

The advantages and disadvantages need to be identified here, especially with authentication in mind (as noted below). This might also influence whether we actually need a daemon in the backend. (Even if it only changes a must to a can)

Authentication

A connection must be authenticated. Icinga Web has the only authority to do so. So the connection must only be established after the user logged successfully into Icinga Web. The best would be if there are no or just minimal changes to the webserver configuration necessary.

This would allow us to still rely on the browser transmitting the session cookie with each connection attempt, so the request can be authenticated with the current session mechanism in Icinga Web.

Hint
Since the functionality won't be integrated into Icinga Web for now, it might be difficult to authenticate the user over a websocket connection. Notifications Web might need to provide a AuthenticationHook and persist the session on its own so that the backend daemon has access to it.

Browser Integration

For this we need a ServiceWorker, no questions here. Though, what I didn't fully explore is when and how a service worker is being updated. (If the source changes) Also, what happens with workers of windows/tabs that are inactive for a longer time. Especially on mobile, as the power optimizations are fairly aggressive there.

Though, before a service worker can display notifications, we have to ask for permission. For the moment, this can be performed right after login, although it's not best practice. We can apply the best practice later on in the development cycle.

Database Polling?

It is currently out of scope to implement a direct communication with the notifications daemon. The database holds the information already when who got informed about what. This means that if a contact is notified over e.g. email, the desktop notification appears in addition. This also solves the problem that desktop notifications are volatile, and there's no persistence unless specifically implemented, which is not required for now.

Things to Discuss (For later)

• The look of notifications. Not all browsers support the same functionality and we need to find a common ground here. Once that's done, we have to decide what a notification displays.
• Where can the user enable desktop notifications? It's best practice to only ask for permission if the user wants to opt-in. But that requires a button somewhere. How does it look? Where is it shown?