Docs / Backend / Notification Server
ven_notify.php
Notification Server
Register push devices and deliver them via a service worker.
The frontend side (
venjs.notification) is documented under Core → Notifications.ven_notify.php
Receives a POST with { deviceId, type } and appends a structured entry to notification_handler.txt (create the file with write permissions).
| Field | Required | Description |
|---|---|---|
deviceId | Yes | Client-generated device identifier. |
type | No | Defaults to "unknown". |
Response (success):
{ "status": "success", "code": 200, "message": "Device successfully registered ..." }CORS:
ven_notify.php currently sends Access-Control-Allow-Origin: *. For production, restrict it to your known origins and add the same API-key handshake used by ven.php.Client registration from logic
In a real app the notification setup lives in logic/notifications.js and is called from your entry point or settings page.
// logic/notifications.js
export const initNotifications = async () => {
await venjs.notification.registerServiceWorker("/sw.js");
const id = await venjs.notification.ask("/ven_notify.php");
// id is now logged server-side in notification_handler.txt
return id;
};sw.js (Service Worker)
The service worker must live at the site root. It handles three events:
| Event | Behavior |
|---|---|
push | Parses the payload ({ title, content, url, icon }), shows a notification with Open/Dismiss actions. |
notificationclick | Focuses an existing matching client or opens data.url; close action dismisses. |
activate | Claims clients so the worker controls pages immediately. |
// Payload pushed from your server:
{
"title": "VenJS Update",
"content": "You have a new message.",
"url": "/messages",
"icon": "/icon/logo.png"
}Note: To actually send pushes you need a push service / VAPID integration on the server.
ven_notify.php only captures device subscriptions; wire it to your push provider to deliver real notifications.