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.
• 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

Does the plugin send data anywhere by itself?

No. It only responds to authenticated incoming requests. The one outbound request it makes
is a loopback request to your own site, which is part of the WordPress Site Health tests.

Can I use it without the BOROS Vigilon monitoring server?

Yes. The routes return plain JSON and can be consumed by any client that can compute the
HMAC signature, for example a cron script, Zabbix, Icinga or a custom dashboard.

Why is my request rejected with a 403?

Either the signature is wrong, the timestamp is outside the validity window, the nonce was
reused, or the calling IP is not in the allowlist. Enable Enable Debug Output in the
settings temporarily to see the reason, and disable it again afterwards.

Does the Site Health data slow down my requests?

No. Site Health tests run in a twice-daily cron job and the status route serves the cached
result.

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.