BOROS Vigilon Client

BOROS Vigilon Client turns a WordPress installation into a monitored endpoint. It adds two authenticated REST routes that return a structured JSON report about the server, the WordPress installation and its current health. A monitoring server polls those routes; the plugin itself never initiates outbound connections to a third party. The plugin is passive by design. It stores no data of its own beyond its settings and a cached Site Health report, and it answers only requests that carry a valid signature. Reported data

• Server information: PHP version, web server, operating system, disk and memory usage, load average and uptime.
• WordPress information: core version and update status, installed plugins with version, slug and update status, active theme.
• Site Health: the results of the WordPress Site Health tests, collected by a twice-daily cron job and served from cache.
• Database: total size, per-table data, index and reclaimable bytes, row counts, plus cleanup candidates such as expired transients, autoloaded options, post revisions, trashed posts and spam comments.
• Error log: the ten most recent PHP error entries from debug.log, when the file is readable.
• Log files: the size and age of the log files the installation writes, in wp-content, in the plugin log directories below uploads, and at the configured WP_DEBUG_LOG and PHP error_log paths. Metadata only, no log content.
• Composer: whether the installation is Composer-managed, and the installed package versions.
• Realtime resource usage: a lightweight CPU, memory and load snapshot on a separate route.

Authentication Requests are authenticated with an HMAC-SHA256 signature over timestamp:nonce:route, sent in the X-Boros-Vigilon-Timestamp, X-Boros-Vigilon-Nonce and X-Boros-Vigilon-Signature headers, or as Authorization: Bearer. A nonce may only be used once inside the signature validity window, so captured requests cannot be replayed. A 64-character secret is generated on activation. Access can additionally be limited to a list of IP addresses, and the status route is rate limited per endpoint and remote IP. Privacy The plugin transmits no data on its own. It answers requests from whoever holds the shared secret, and the response may contain PHP error messages from debug.log, file paths and server details. Review what your debug.log contains, restrict Allowed IPs to your monitoring server, and treat the secret like a password.

1. Install and activate the plugin.
2. Open Settings > BOROS Vigilon Client. A 64-character API secret is generated on activation.
3. Set Allowed IPs to the address of your monitoring server. The default * allows every address.
4. Copy the secret and the endpoint URLs into your monitoring server.

The endpoints are:

• /wp-json/boros-vigilon/v1/status
• /wp-json/boros-vigilon/v1/realtime

1.7.0

• Added: a logFiles section reporting the size and modification time of the log files the installation writes, so a log growing without bound is visible before it fills the disk. Only file metadata is read, no log content.
• Changed: payload schemaVersion raised to 1.5.

1.6.2

• Changed: the readme no longer lists a screenshot. The image is added in a later release.

1.6.1

• Changed: the debug log is read through SplFileObject, and the leftover pre-1.2.0 rate limit directory is removed through WP_Filesystem. No change to what either one reports or deletes.
• Changed: the uninstall handler and the admin bootstrap no longer leave variables in the global scope.
• Changed: the options cleanup query is built from literals instead of assembled from variables. The SQL it produces is unchanged.

1.6.0

• Changed: the plugin is now BOROS Vigilon Client. The slug, text domain, option keys, filter names, REST namespace and HMAC header names all changed with it, so a monitoring server has to be reconfigured before upgrading.
• Security: the rate limiter and the nonce replay check no longer read a transient and write it back in a second step. Each is a single atomic statement now, so concurrent requests can neither exceed the configured limit nor replay the same captured request twice.
• Security: two provider files were missing the guard that aborts when a file is loaded outside WordPress.
• Added: settings, the cached Site Health report and the cron schedule are carried over from the old names on the first request after the upgrade.
• Changed: the rate limit window is capped at 24 hours.

1.5.0

• Changed: the plugin directory and text domain were renamed, because WordPress.org rejects plugin names that begin with "WP".

1.4.1

• Security: every file under includes/ now aborts when loaded outside WordPress.
• Added: readme.txt and LICENSE.txt with the full GPL-2.0 text.
• Changed: text domain renamed to match the plugin slug.
• Changed: admin settings strings are translatable.

1.4.0

• Added: a databaseSize section with total database size and per-table data, index and reclaimable bytes plus row counts.
• Added: tables are classified as cache, log, history, session, index, content or other, and disposable ones are flagged as cleanup candidates.
• Added: a cleanup section reporting expired transients, autoloaded options and their size, post revisions, trashed and auto-draft posts, spam and trashed comments.
• Changed: payload schemaVersion raised to 1.4.

1.3.0

• Removed: the enableErrorLogProvider setting. Recent debug.log entries are now always part of the status payload.
• Fixed: the realtime endpoint is no longer rate limited, so a five-minute polling interval is no longer throttled.
• Added: each plugin entry carries an explicit slug field.

1.2.0

• Security: nonce replay protection inside the signature validity window.
• Security: support for passing the signature via the Authorization: Bearer header.
• Security: the deprecated ?secret=... query authentication is opt-in and disabled by default.
• Security: minimum secret length raised from 5 to 32 characters.
• Security: uninstalling removes options, scheduled events, transients and rate limiter state.
• Changed: the rate limiter is a sliding window scoped per endpoint and remote IP.
• Fixed: php_version and plugin_version are no longer skipped during Site Health collection.

1.1.1

• Fixed: Site Health test callables are resolved correctly, and theme_version and plugin_theme_auto_updates are retained.
• Fixed: wp-config.php path and loopback request URL detection.

1.1.0

• Added: Site Health metrics are collected by a twice-daily cron job and served from a cache.

1.0.2

• Added: HMAC signature verification.
• Added: update status fields for the core and plugin providers.

1.0.1

• Maintenance release; no functional changes.

1.0.0

• Initial release.