whmcs-vpsmanager/docs/BACKUPS-REGRESSION.md

Informe de regresión — 19/09/2026

Implementación local, desactivada. Falta observar la contratación real; este informe no es una aceptación de producción.

Base y cambios

Base local y HEAD remoto consultado: 1174c120dec0982b4c628a353c66cdaeab894b1e (main, limpio). Worktree separado en rama feature/client-backups-summary; el checkout original permanece en main. Sin push, merge ni despliegue.

Archivos de runtime añadidos: lib/BackupAccess.php, BackupOption.php, BackupCache.php, BackupHttp.php, BackupParser.php, Backups.php, templates/backups.php, templates/backups.tpl. Cambios de integración: require del componente, parámetro opcional en registro de botones, botón condicional y callback Backups; nueva sección privada en config.example.php. Pruebas y fixtures saneados bajo tests/; documentación bajo docs/. El auditor extiende a tests/backups.php las excepciones existentes para sentinelas FAKE_ y URLs inválidas de pruebas con dominio example.invalid; no se han eximido archivos de runtime.

La opción configurable del módulo, sus posiciones y las implementaciones existentes de provisioning, suspensión/reactivación, panel, Graphite, snapshots, firewall y reinicio/parada/arranque no se modifican. Los cinco botones anteriores siguen registrados incluso sin parámetros/configuración. Las dependencias nuevas fallan de forma aislada/cerrada para copias.

Verificaciones ejecutadas

Runtime: PHP CLI 8.1.2-1ubuntu2.26, DOM/libxml del paquete Ubuntu php8.1-xml, Node.js v22.11.0. PHP no estaba en PATH; se reutilizó el binario local de la entrega anterior y se extrajo DOM bajo work/, sin instalar paquetes del sistema. Las suites PHP usan -n, con DOM cargado expresamente para backups, sin cURL real. Los comandos siguientes usan php como abreviatura de ese runtime.

Comprobación	Resultado
Antes del cambio: php -n tests/run.php	PASS: 192 aserciones, HTTP simulado
Antes del cambio: node tests/frontend.cjs	PASS: 24 aserciones
Después: php -n -d extension=/ruta/dom.so tests/backups.php	PASS: 192 existentes + 137 nuevas
Después: node tests/frontend.cjs	PASS: 24 aserciones
Diagnóstico separado: php -n test-diagnostico.php /ruta/checkout	PASS: 35 aserciones
php -l en los 22 PHP del checkout y del diagnóstico	PASS
node --check assets/metrics.js	PASS, JS sin cambios
git diff --check	PASS
python3 tools/audit.py	PASS heurístico; revisión manual descrita abajo

Cobertura nueva ejecutada: claves exactas y grupos aplicables, no herencia de opciones de otros grupos, duplicados ambiguos, conflicto de ambas claves/tipos con incidencia segura, lista estricta sintética, valores ausentes/nulos/desconocidos, host y límites; detalle correcto/equivocado/resumen/login; tablas y filas reordenadas/unión por ID; contadores/tamaños ausentes; cinco/seis/cero filas; Filled, idle y estado desconocido; fechas y DST ambiguo/inexistente; HTTP 200/301/302/401/403/404/500, retorno falso cURL para fallo TLS/timeout y aborto por tamaño; URL fija y política TLS/redirect; propietario/sin sesión/permiso delegado denegado y permitido con mocks; alteración de ID desde callback real; no consultas denegadas; caché aislada por servicio/host/configuración, revocación, TTL, stale y caducidad; escape y sentinelas públicos.

El caso TLS simula el retorno de error de cURL y verifica sus opciones; no realiza un handshake real. El caso de delegado simula el contrato de CurrentUser/permiso; no ejecuta WHMCS. La prueba de integración llama al callback de producción con la frontera de sesión y consultas Capsule simuladas, incluyendo servicio ajeno: no se limita a pasar parámetros que ya se suponen autorizados, pero no ejecuta el router cifrado real.

Renderizado y privacidad

Se ejecutó Backups::render desde el callback y se guardó la evidencia sintética vista-backups-fixture.html junto a la entrega. Contiene la vista propia dentro de un contenedor HTML representativo, no el tema completo de WHMCS. Se comprueba ausencia de proveedor, hosts, URL privada, credencial falsa, número interno, enlaces y conteos de ficheros; el contenido malicioso queda escapado. Smarty recibe un único campo HTML propio. No se ha ejecutado Smarty ni una sesión de navegador sobre WHMCS: no se declara validada la página completa real.

Los tres fixtures se copiaron exclusivamente del ZIP saneado proporcionado. Revisión manual: hosts .invalid, usuario de prueba e IP documental; referencias públicas al proyecto del proveedor conservadas solo como material de parser. No se han copiado exportaciones originales, capturas de clientes, configuración privada ni credenciales reales. El escáner inicialmente señaló dos sentinelas de pruebas, revisados y cubiertos con las mismas excepciones acotadas que la suite existente. No publicar ni desplegar fixtures bajo una ruta HTTP.

Pendientes reales — no son PASS

• Los dos IDs de servicio autorizados para diagnóstico y las observaciones de presencia/tipo/valor en contratado y no contratado. Los IDs de definición de opciones y optiontype=3 no cubren esta verificación.
• Fijar la regla exacta observada, con tests, y retirar el diagnóstico temporal de la instalación si se utiliza. Mientras tanto listas activas vacías y confirmación desactivada.
• WHMCS/tema/Smarty reales: firma efectiva del callback de botones, permiso products, CurrentUser, enrutamiento, propietario/delegados e IDOR, formato horario y semántica del campo exclusivamente administrativo, ausencia en emails/pedido/factura/página completa.
• Cuenta del origen, permisos de solo lectura efectivos, mecanismo de autenticación, endpoint, TLS real, zona horaria y estructura de detalle de un host realmente sin copias.
• Caché fuera de todos los alias HTTP, permisos del usuario PHP, exclusión del CDN/caché de página y verificación entre sesiones.
• Regresión operativa en staging: Graphite/panel/snapshots/firewall/reiniciar/detener/iniciar/suspensión/reactivación. El código existente se conserva y sus pruebas simuladas pasan, pero no se han ejecutado órdenes reales ni se garantiza desde este entorno la instalación productiva.

Instalación y rollback: BACKUPS.md. Diagnóstico temporal separado y no integrado en runtime: carpeta diagnostico de la entrega, con instrucciones para revisión. La implementación no está habilitada para clientes y no se considera terminada la validación de contratación.