Comportamiento de la caché para usuarios con sesión iniciada
La política HTML predeterminada de POM Cache prioriza a los visitantes anónimos. Una cookie de autenticación de WordPress impide la entrega estática anticipada y evita que la respuesta autenticada se escriba sobre el index.html público.
El archivo en caché puede permanecer en el disco para los visitantes que no han iniciado sesión; omitirlo no requiere eliminarlo.
Por qué la autenticación cambia la decisión
Una respuesta con sesión iniciada puede diferir incluso cuando su URL es idéntica:
- WordPress puede añadir la barra de administración;
- los temas pueden mostrar enlaces de edición o de cuenta;
- los menús pueden depender del rol o de la membresía;
- los datos privados, en borrador o restringidos pueden hacerse visibles;
- los nonces y los valores específicos del usuario pueden aparecer en el marcado.
POM Cache no crea un archivo por usuario ni por rol. Sin una dimensión de variante en la clave de caché, compartir cualquiera de esas versiones no sería seguro.
Dónde se produce la omisión
El drop-in anticipado reconoce los nombres de las cookies de autenticación de WordPress antes de que el objeto de usuario normal esté disponible. Cuando encuentra una, marca la solicitud como no cacheable y devuelve el control a WordPress.
Después del renderizado, la compuerta del búfer de salida vuelve a comprobar. Esa segunda comprobación evita que una página con sesión iniciada se publique si el estado de autenticación apareció o cambió durante la solicitud.
Las reglas directas de Apache y CDN deben implementar el mismo límite de cookie porque se ejecutan antes de que PHP pueda proteger la solicitud.
Prueba las vistas públicas y autenticadas por separado
- Elige una página que cambie visiblemente para un editor, como una con la barra de administración o un enlace de edición.
- Elimina la caché HTML actual del sitio.
- Abre la página en una ventana privada limpia y permite que se genere.
- Vuelve a cargar en privado y demuestra un acierto público.
- Abre la misma URL canónica en un perfil de navegador diferente donde hayas iniciado sesión.
- Confirma que los controles autenticados aparecen correctamente.
- Confirma que la respuesta no es un acierto anticipado de POM Cache.
- Vuelve a la ventana privada y verifica que el archivo anónimo sigue siendo correcto.
No muevas cookies entre los dos perfiles. Una ventana de prueba que estuvo con sesión iniciada puede conservar una cookie de omisión después de cerrar sesión.
El estado de contraseña y de comentario se trata de forma similar
Las cookies de contraseña de entrada y de autor de comentario también omiten la página estática. No significan necesariamente que el visitante tenga una cuenta de WordPress, pero pueden cambiar la salida de la página o revelar contenido protegido.
Usa un contenedor de cookies nuevo al validar la caché anónima después de probar esas funciones.
La entrega tardía es opcional, no automática
Una vez que WordPress se ha cargado, POM Cache conoce el usuario, las capacidades y el objeto consultado. Realiza una búsqueda tardía del archivo, pero la política predeterminada no sirve el archivo desde esa fase.
Un desarrollador puede permitir un caso tardío con alcance estricto mediante pom_cache_can_serve_cached_file. Cualquier política de ese tipo debe demostrar que:
- la ruta seleccionada es idéntica para el público autenticado permitido;
- ningún nonce, barra de administración, enlace de edición, contenido privado o dato de cuenta entra en el archivo;
- las capas directas de Apache y CDN no omiten la decisión de la aplicación;
- la regla está cubierta por una prueba de fugas repetible.
Se trata de un punto de extensión para vistas públicas equivalentes excepcionales, no de un interruptor general de «almacenar en caché a los usuarios con sesión iniciada».
Si un visitante con sesión iniciada ve contenido público en caché
Trátalo como un incidente de la cadena de entrega:
- captura la URL, las cabeceras de respuesta y los nombres de las cookies sin exponer sus valores;
- identifica si la respuesta provino del CDN, de Apache o de PHP;
- desactiva la ruta de caché ascendente insegura;
- purga el HTML de origen y las entradas de borde relevantes;
- verifica las exclusiones de cookies efectivas;
- vuelve a probar con sesiones anónimas y autenticadas separadas.
Usa Logged-in content leak check para el flujo de diagnóstico completo.