=== BOROS Vigilon Client ===
Contributors: crocus99
Tags: monitoring, rest-api, site-health, server-status, uptime
Requires at least: 5.9
Tested up to: 7.1
Requires PHP: 8.0
Stable tag: 1.6.2
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Exposes server, WordPress and Site Health information as authenticated JSON, so a central monitoring server can watch many installations.

== Description ==

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.

== Installation ==

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`

== Frequently Asked Questions ==

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

== Changelog ==

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

== Upgrade Notice ==

= 1.6.0 =
REST routes moved to `/wp-json/boros-vigilon/v1/` and the HMAC headers are now
`X-Boros-Vigilon-*`; reconfigure your monitoring server first. WordPress sees the
rename as a separate plugin: deactivate the old one, install this and activate it.
Secret and settings carry over.

= 1.5.0 =
The plugin directory changed, so WordPress sees this as a separate plugin. Deactivate the
old one, install this one and activate it. Your secret and settings are kept.

= 1.3.0 =
Recent `debug.log` entries are now always included in the status payload. Review what your
debug log contains before updating.
