# Settings Validation ## Why this exists Cacti settings are written from several places: the web UI (`settings.php`), CLI utilities under `cli/`, and (planned) JSON-RPC endpoints. Each of those paths previously carried its own ad-hoc checks for the same setting, and the checks drifted apart as code was added. The intent of `CactiSettings::validate()` is to put the constraint definition next to the setting itself so every write path uses the same rules. A setting in `include/global_settings.php` declares its constraints alongside the existing keys (`method`, `default`, `max_length`, ...). The validator runs the entire posted set in one pass and returns a `{name => message}` map. An empty map means the input is valid. ### Why constraints are declared as closures `include/global_settings.php` is loaded from `include/global.php` *before* `include/vendor/autoload.php`. Eagerly instantiating `new Assert\NotBlank()` inside the array literal would fatal at file-load time because the Symfony Validator classes are not yet loadable. Wrapping each constraint in an arrow function (`fn() => new Assert\NotBlank()`) defers the instantiation until `CactiSettings::validate()` runs the closures. The `use Symfony\Component\Validator\Constraints as Assert;` import at the top of the file is a compile-time alias and does not trigger autoloading. ## How `CactiSettings::validate` is used in `settings.php` `save_settings()` builds a snapshot of posted values via Cacti's request-var helpers (`gnrv`) and calls the validator before writing any rows: ```php require_once(CACTI_PATH_LIBRARY . '/CactiSettings.php'); $snapshot = []; foreach ($settings[grv('tab')] as $field_name => $field_array) { $snapshot[$field_name] = gnrv($field_name); } $violations = CactiSettings::validate($snapshot, $settings); if (cacti_sizeof($violations) > 0) { foreach ($violations as $name => $message) { $_SESSION['sess_error_fields'][$name] = $name; $_SESSION['sess_field_values'][$name] = $snapshot[$name] ?? ''; raise_message('cacti_settings_' . $name, ..., MESSAGE_LEVEL_ERROR); } header('Location: settings.php?tab=...'); exit; } ``` When violations are present the request is rejected before any `REPLACE INTO settings` runs. The user is redirected back to the same tab with the error highlighted. ## How to add constraints to a setting 1. Open `include/global_settings.php` and find the setting definition. 2. Add a `'constraints'` key holding an array of closures, each returning a Symfony constraint instance. 3. The `use Symfony\Component\Validator\Constraints as Assert;` alias is already imported at the top of the file, so constraints read as `fn() => new Assert\Range(...)`. 4. Wrap any custom `message:` argument in `__()` so the message participates in Cacti i18n. Example: ```php 'snmp_timeout' => [ 'friendly_name' => __('Timeout'), 'method' => 'textbox', 'default' => '500', 'max_length' => '10', 'constraints' => [ fn() => new Assert\Regex(pattern: '/^\d+$/', message: __('must be a positive integer (milliseconds).')), fn() => new Assert\Range(min: 1, max: 600000), ], ], ``` When a `Choice` list duplicates a canonical array from `global_arrays.php`, derive the choices from that array inside the closure rather than restating the values: ```php 'constraints' => [ fn() => new Assert\Choice(choices: array_merge( array_keys($GLOBALS['poller_intervals']), array_map('strval', array_keys($GLOBALS['poller_intervals'])) )), ], ``` Both string and integer forms of the keys are accepted because `$_POST` values arrive as strings while the canonical keys are integers. ## Constraint types used in the pilot See the [Symfony Validator reference](https://symfony.com/doc/6.4/validation.html) for the full catalog. The pilot uses: - `Assert\NotBlank` -- value is present and non-empty. - `Assert\Length` -- string length within `min`/`max`. - `Assert\Range` -- numeric value within `min`/`max`. - `Assert\Choice` -- value is one of an enumerated list. Use this for any setting that is rendered as a `drop_array`. - `Assert\Regex` -- value matches a pattern. Useful for "is this an integer string" since `$_POST` values arrive as strings. - `Assert\Positive` -- value is strictly greater than zero. ## Migration template for the next batch For each setting you want to constrain: 1. Identify the setting's existing implicit rule (e.g. `method` is `drop_array` with a fixed key set, or `max_length` is `'255'`). 2. Translate that rule to a constraint object. `drop_array` becomes `Assert\Choice` over the array keys. `max_length` becomes `Assert\Length`. Numeric textboxes typically need `Assert\Regex` plus `Assert\Range`. 3. Add a unit test in `tests/Unit/Security/InputValidation/CactiSettingsTest.php` that exercises the new constraint with a synthetic definition (do not depend on `include/global_settings.php` from the test). 4. Run `composer test` and confirm the new case passes. ## Translator wiring (known limitation) `CactiSettings::validator()` builds the validator with `Validation::createValidator()` and does not pass a `TranslatorInterface`. Symfony's default English messages render regardless of the active Cacti locale. Custom messages declared in `global_settings.php` should be wrapped in `__()` so the operator-facing text is translatable through Cacti's own i18n stack. Wiring a `TranslatorInterface` so that the framework's built-in constraint messages also translate is a planned follow-up. ## Defense in depth The constraint layer supplements existing checks rather than replacing them. - The form-render method (`drop_array`, `dirpath`, `filepath`, `textbox_password`) still enforces its implicit rules in `save_settings()`. For example, `dirpath` continues to verify the directory exists before storing. - Any post-save handler (cache-clear, poller restart, log rotation) keeps whatever validation it already performs. - The constraint check runs first and short-circuits the write, so downstream handlers see only values that already cleared the declared rules.