Troubleshooting · TikiWiki · CAS · PHP
TikiWiki 24, CAS y una pantalla en blanco: cómo una incidencia acabó llegando al equipo oficial
Una historia real de operación de aplicaciones: una actualización aparentemente correcta, un login mediante CAS que parecía funcionar y una página en blanco que obligó a seguir el flujo paso a paso hasta localizar el punto exacto del fallo.
Contexto
Durante una actualización de una plataforma basada en TikiWiki a la versión 24, apareció una incidencia que inicialmente parecía relacionada con la autenticación corporativa mediante CAS.
La actualización había finalizado y la aplicación parecía responder correctamente. Sin embargo, en determinadas condiciones, después de iniciar sesión, algunos usuarios terminaban viendo una pantalla completamente en blanco.
El síntoma
El comportamiento era especialmente incómodo porque no mostraba un error claro al usuario. El flujo, simplificado, era el siguiente:
Usuario
↓
CAS
↓
Retorno a TikiWiki
↓
Validación del usuario
↓
Pantalla en blancoDesde fuera, podía parecer que CAS era el origen del problema. Pero la autenticación llegaba a producirse, así que había que mirar más allá.
Primeras hipótesis
Antes de entrar en el código, revisé los puntos habituales en una incidencia de este tipo:
- Configuración de CAS.
- Certificados y conectividad.
- Sesiones PHP.
- Permisos y cachés.
- Logs de aplicación y servidor web.
Ninguno de esos puntos explicaba completamente el síntoma. El problema no parecía estar en el acceso inicial, sino en algún punto posterior al retorno desde CAS.
La investigación paso a paso
Cuando una incidencia no deja una traza evidente, una estrategia útil es reconstruir el recorrido exacto que sigue la aplicación y localizar el último punto que funciona correctamente.
En este caso, el objetivo fue aislar el punto concreto donde TikiWiki dejaba de construir correctamente la respuesta. Para ello, fui acotando el flujo de autenticación y revisando qué ocurría después de que CAS devolviera el control a la aplicación.
El hallazgo importante fue que el usuario parecía estar correctamente autenticado, pero la sesión que debía quedar preparada dentro de la aplicación no se generaba como se esperaba.
El hallazgo
El problema quedó localizado en una parte concreta del proceso de inicio de sesión. Un componente PHP relacionado con la generación de la sesión no estaba tratando correctamente el caso de acceso mediante CAS.
- La autenticación externa parecía correcta.
- La aplicación recibía el retorno.
- La sesión interna no quedaba bien construida.
- La interfaz no llegaba a renderizarse.
- El usuario solo veía una pantalla en blanco.
Comunicación y corrección
Una vez localizado el punto del fallo, preparé la información necesaria para comunicarlo al equipo oficial de desarrollo de TikiWiki: descripción del síntoma, contexto de uso con CAS, comportamiento observado y zona del flujo donde se producía el problema.
El caso fue revisado y finalmente corregido por el equipo del proyecto. Además, la colaboración quedó reconocida en espacios oficiales de la comunidad.
Lecciones aprendidas
No asumir que el fallo está donde parece
Que el síntoma aparezca durante el login no significa necesariamente que el problema esté en CAS.
Seguir el flujo completo
La clave estuvo en revisar el recorrido desde la autenticación hasta la generación de sesión.
Los errores silenciosos exigen método
Una pantalla en blanco obliga a trabajar por descarte y a entender el comportamiento interno.
Documentar bien ayuda a todos
Un reporte claro facilita que el equipo responsable pueda reproducir, validar y corregir.
Reflexión personal
Después de años en soporte, sistemas y operación de aplicaciones, cada vez tengo más claro que resolver incidencias complejas no consiste solo en conocer comandos o herramientas. Consiste en observar, formular hipótesis, descartar, aislar y documentar.
Este caso es un buen ejemplo de cómo una incidencia aparentemente local terminó contribuyendo a mejorar el propio producto para otros usuarios.