Class ServerPushKeys

Why the server needs a key pair of its own. A Browser subscribes with exactly one applicationServerKey - pushManager.subscribe takes one, and the endpoint it returns is bound to it - so the * subscriptions need one VAPID pair, and it cannot be any application's: the server has no application selected at that point, and the iiziSystem application carries none. A server whose settings carry no $pushNotifications container must still be able to answer /iizi-push/keys for *, so the pair is acquired here: generated on first use with VAPIDKeys.generateKeys() and persisted through the server's own property factory, in FILE_NAME beside the spool.

Precedence. An operator may configure the server's container by hand as the $push child of the $pushNotifications settings container. When that child carries a valid VAPID pair it is used as it is. When it exists without a valid pair, its other members - the VAPID subject and the Firebase configuration - are kept and the generated pair fills the two keys. When there is no such child, the generated container serves alone.

The credentials file's [server] section (PUSH-CREDENTIALS.md section 3.6, ruled 2026-09-26) sits above both, member by member (S-4): a member present there wins, an absent one falls through to the $push child, and the VAPID pair falls through once more to the generated pair. Its fcmServiceAccountFile names Google's key file, whose text the credentials read when a send needs it and hand over here as the fcmServiceAccount member; a file that cannot be read leaves that member empty, which the FCM transport reports as not configured. The section is read on every call, so an edit of the file takes effect at the next lookup, as the settings do.

Resolved at use. The configured child is read from the live settings on every call, so an edit takes effect without a restart, as it does for a hot-deployed application. The generated container is re-read when its file's modification time changes, so an operator may replace the file; it is otherwise held, because it is the server's own and nothing deploys it.

Key files (PUSH-KEYFILES-DESIGN.md sections 9 and 9.3). The section's VPrivKeyFile is read by the credentials and arrives here as the section's pair; a named file that cannot be used still wins, leaving VAPID for * not configured. A settings container that names a VPrivKeyFile beside its public key carries a pair for this class, and the application configurations resolve the file. The generated file is written owner-only (mode 0600 where POSIX applies) and, when found with a broader mode, is narrowed by the server itself with a WARNING - it is the server's own file - never refused.

Fail closed. A file that exists but cannot be loaded, or holds no valid pair, is never overwritten: the pair in it may be the one every existing * subscription is bound to. The failure is logged SEVERE and get() answers null, which the endpoints report as "not configured", until the operator repairs or removes the file. The same holds when a freshly generated pair cannot be written: a pair that lives only in memory would bind subscriptions that die at the next restart, which is worse than a clear refusal now.

Rotation (rotate()) generates and persists a new pair. Every existing * Browser subscription is bound to the old public key and the push services will refuse sends signed with the new one, so a rotation is a deliberate act that invalidates them; it is offered for an administration surface and has no caller in the server today.

Thread-safe.