How Push Notifications reach the user
- In the Browser: Web Push (VAPID). On Apple Browsers, Safari 16.4 or later.
- In iiziRun on Android and iOS: Firebase Cloud Messaging (HTTP v1); iOS devices receive through Firebase.
- A Push Notification (PN) that arrives while the application's page is in front is shown once as an in-app message; the system notification appears only when no page showed it, in the Browser and in iiziRun.
- A tap opens the application the notification names; in iiziRun, a tapped notification for another application switches to it after a confirmation.
- Receipts (shown, clicked) and in-session delivery, by default both in the session and as a notification.
Keys and secrets
- The server makes and keeps its own VAPID key pair. Its own Push keys may be key files or entries of the secrets store.
- An application's secrets – its VAPID private key and its Firebase service account – are kept only in the machine's secrets store, never in the application's files. iiziGo's Push page generates the key pair and imports the service account into the store, and shows for each secret whether this machine's store holds it.
- A VAPID token always carries a subject: the application's VAPID Subject, else the server's own, else
https://support.iizi.co. iiziGo's Push page warns about a public key without a subject.
Subscribing
- Subscribe at sign-in. iiziGo's Push page has the setting “Subscribe at sign-in” (off by default): the server subscribes the device of a user who signs in to the application, once, to the application's Push Notifications. A phone asks for its permission at the first sign-in; a Browser is subscribed only when its permission is already granted.
- Application Java subscribes, unsubscribes and resets a device through
IPushNotificationAPI; a subscribe action for a button asks the user on its click. - A page whose Push channel is created before its Service Worker is registered waits for the registration.
- The client's Push API (
izPush) takes its credential as HTTP Basic or as a Bearer token (setCredential). A Browser whose Push request is refused is answered without a sign-in challenge, so it shows no dialog of its own. A request that gets no reply says that there is no network or the server cannot be reached.
iiziRun Developer and iiziRun Custom
- Push Notifications in iiziRun Developer and iiziRun Custom come only from Mindus's own servers: the Firebase sending key of these two apps is not given out. An application on another server gets no Push Notifications inside them; test Push Notifications in a Browser, or in a Customized iiziRun built with your own Firebase project.
- iiziRun Developer's Push view shows the device's Push state – the notification permission, with a button to ask for it, the transport, whether the device holds a token, and the application and server last launched. Subscriptions are made by the launched application.
On the server
- Push Notifications to Browsers are offered over a secure (HTTPS) port only.
- The server log names every subscribe and unsubscribe – application, Topic, transport and a shortened device ID, never the token – and how each send went out.
- A Push key's fingerprint is shown in logs by its first eight characters.
Moving an application with Push Notifications from 4.x? See Push Notification secrets. Push Notifications in an installed web app are not claimed for 5.0 (Known limits).