Hola Carles.
Te comento que en la implementación que estoy desarrollando con Hix, me tope con el problema que sin tener ningún error, me salía de sesión de la aplicación y tenía que volver a ingresar de nuevo. Esto me sucedía cuando trabajo con el dominio que tengo configurado con Cloudflare, a los subdominios configurados segun el cliente, por lo que tengo Hix en distintos puertos 81,82,83, etc.
Investigando con la ayuda de Antigravity, el problema se da porque Cloudflare cambia Ip's constantemente, entonces, se solucionó el problema con una implementación hecha por Antigravity, y este ese el resumen del problema y solución planteada por Antigravity.
Problema Detectado: Al desplegar aplicaciones Hix detrás de Cloudflare, se detectó un comportamiento errático en la gestión de sesiones:
Bucle de Redirección: Tras un login exitoso vía AJAX, el navegador a veces ignoraba la cabecera Set-Cookie enviada por el servidor, provocando que la siguiente petición fuera redirigida nuevamente al Login al no encontrar una sesión válida.
Desconexiones Aleatorias: Debido a la rotación de IPs de los nodos de Cloudflare, la validación interna de Hix (USessionReady()) fallaba intermitentemente, o el USESSID rotaba involuntariamente, dejando al usuario fuera del sistema.
Causas Técnicas:El navegador no siempre persiste las cookies de sesión inmediatamente tras una respuesta AJAX si hay una redirección rápida (window.location.href).
La dependencia estricta del USESSID volátil de Hix choca con la arquitectura distribuida de los proxies modernos.
Solución Implementada ("Handshake de Cookies" + Persistencia en DB):Para resolver esto de forma definitiva, implementamos un sistema de tres capas:
Handshake de Cookies (Frontend/Backend): En lugar de confiar solo en la cabecera Set-Cookie del servidor, el backend envía el nombre y valor del token de sesión en el cuerpo del JSON de respuesta del login:
harbour
// Backend (sem.prg)
cJson := '{"status": "success", "token_name": "' + cTokenName + '", "token": "' + cPersistToken + '"}'
?? cJson
El frontend captura este JSON y graba la cookie manualmente mediante Javascript antes de la redirección:
javascript
// Frontend (sem.view)
if (data.token && data.token_name) {
document.cookie =${data.token_name}=${data.token};path=/;SameSite=Lax;Secure;
}
window.location.href = data.redirect;
Rescate de Sesión en DB (Golden Loop): Creamos una tabla de persistencia (hix_sessions) en MySQL. En cada petición (
sem.prg
), la aplicación verifica si la sesión de Hix está activa. Si falla, busca el token persistente en la cookie y "rescata" la sesión desde la base de datos:
harbour
IF !USessionReady()
hDbSession := GetWebSession( Ucookie(cTokenName) )
IF !Empty( hDbSession )
USessionStart()
USession( 'user_name', hDbSession['usuario'] )
// ... restaurar entorno ...
ENDIF
ENDIF
Sincronización Permanente del USESSID: Para manejar la rotación del ID nativo de Hix, implementamos un "Golden Loop" que, en cada petición válida, actualiza el USESSID actual en la base de datos de persistencia, asegurando que el "vínculo" nunca se rompa.
Resultado: La aplicación ahora es 100% estable. El usuario puede navegar, realizar procesos POST/AJAX largos y refrescar la página sin perder la sesión, incluso bajo las reglas más estrictas de seguridad de Cloudflare.En el contexto técnico de Hix, más que una variable de memoria tradicional (como las de Harbour), USESSID es el nombre de la Cookie de Sesión.
Con esto, ya no tuve el problema de salida de sesión.
Adicionalmente Antigravity ha escrito estas solicitudes o mejoras, que se pudieran hacer a Hix (Se manda Antigravity, jejejeje)
USessionStorage( cType, hConfig )
Sería ideal poder cambiar el motor de almacenamiento de las sesiones. Actualmente, Hix las guarda solo en la memoria RAM del servidor.
Para qué sirve: Permitiría que las sesiones se guarden automáticamente en una tabla de MySQL o en un servidor Redis.
Beneficio: Si el servidor se reinicia o si hay una gran carga de usuarios, las sesiones no se pierden nunca, ya que están en la base de datos y no en la RAM volátil.USetSessionScope( cPrefix )
Función para definir un "Ámbito de Sesión" o prefijo.
Para qué sirve: Permitiría que el desarrollador elija el nombre de la cookie (por ejemplo, USESSID_APP1).
Beneficio: Resolvería el problema de conflicto de sesiones cuando tienes varias aplicaciones de Hix corriendo bajo el mismo dominio o subdominio. Actualmente, si no tenemos cuidado, una aplicación "pisa" la sesión de la otra.USessionIgnoreIP( .T. )
Interruptor para ignorar el cambio de IP del cliente.
Para qué sirve: Obligaría a Hix a validar la sesión únicamente por el token de la cookie y no por la combinación de Cookie + IP.
Beneficio: Es vital para aplicaciones que usan Cloudflare, balanceadores de carga o usuarios móviles (celulares) que cambian de antena y, por ende, de IP constantemente. Esto evitaría que el sistema los saque "por seguridad" cuando en realidad solo cambió su IP.URescueSession( cToken )
Función nativa para rescatar una sesión desde un token externo.
Para qué sirve: Si la sesión nativa de Hix falla, esta función permitiría pasarle un token guardado previamente (como nuestro SEM_TOKEN) y que Hix "re-hidrate" la sesión automáticamente.
Beneficio: Facilitaría enormemente implementar la persistencia de "Recuérdame" por varios días sin que el programador tenga que hacer toda la lógica de base de datos manualmente.
Te dejo acá el problema y solución que se implementó y quedo atento a tus comentarios.
Saludos cordiales.
Carlos.
