New: Settings page rebuilt with React UI and REST API

[KingYes]

✨ PR Description

1. Problem & Context

Settings page migrated from WordPress native forms to React UI backed by REST API, enabling modern component reuse and decoupling frontend from admin-menu-based rendering.

2. What Changed (Where)

File	Change
class-aal-rest.php	Added /settings GET/PUT routes and /logs/erase POST; new check_settings_permissions() validates nonce + admin cap
class-aal-settings.php	Gutted legacy form handlers; now only renders <div id="aal-settings-root"> container for React mount
settings.js (new)	React component managing form state, API calls, validation feedback via Notice components
api.js	Added fetchSettings(), saveSettings(), eraseLogs() wrappers passing nonce via custom header
package.json	Build now includes settings-index.js entry point

3. How It Works

Settings endpoint returns schema + current values; React component renders inputs tied to state, POSTs changes to REST endpoint. Nonce passed in X-AAL-Settings-Nonce header (created server-side, injected via window.aalAdmin). Backend validates: logs_lifespan as non-negative int-or-empty, yes/no flags, IP source against whitelist. Erase endpoint gated by aal_allow_option_erase_logs filter.

4. Risks

REST endpoint lacks rate limiting (could spam settings updates). Nonce regeneration per pageload means concurrent requests fail—consider session-bound nonce or longer TTL. Plugin-side validation mirrors frontend (logs_lifespan range, enum values) but no assertion that schema matches saved settings structure—schema drift could silently skip unknown keys.

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}