Crónica de una migración con instalación complicada III - Error 403 - Unauthorized

Continuación de la Primera Parte y Segunda Parte.

Después de la primer instalación fallida, revisamos todas las propiedades de la KB para analizar cuáles eran las que podían estar afectando el comportamiento.

Nivel	Propiedad	Valor	Comentario
Version	Web User Experience	Previous Version Compatible
Version	On session timeout	Ignore	Se ve influida por la propiedad Javascript debug mode
Environment /Security	Encrypt URL Parameters	NO	(Aunque algunos objetos encriptan sus parámetros)
Generator	Javascript debug mode	NO	Comprime css y js Además influye en la propiedad On session timeout

Leyendo el wiki y por motivos históricos que no logro comprender totalmente, vemos que la propiedad Javascript debug mode, además de manejar la compresión de css y js y el encriptado de parámetros en las llamadas Ajax (las que hacen los objetos web para los eventos isValid, para las rules, etc) influye también cuando el modelo no es smooth en la propiedad de On session timeout, aunque de una forma que no está bien documentada o no la encontre explicacion.

Para ver si lográbamos bajar la cantidad de errores 440, lo que definimos fue:

* No mezclar versiones en el balanceo. Todos los nodos GX16 o todos Evo3.
* Pasar Javascript debug mode a YES.

Lamentablemente este cambio nos obligó a hacer un Rebuild all (unas 6 horas), pues genera el código javascript diferente, y eso nos demoró otro dia mas la instalacion. Clone la KB con KBClone y luego hice el Rebuild all, y se lleno el disco de la KB!. Esto fue un error mío que no verifique que tuviéramos el espacio suficiente.

Una vez pasado esto, hicimos el empaquetado y volvimos a instalar, esta vez en dos nodos con GX16.

No apareció ningun error 440, pero si empezaron a aparecer cantidad de errores 403 - Unauthorized.

Volvimos atrás la instalación nuevamente y volvimos a analizar los problemas.

403 - Forbidden - Unauthorized

Hay varios motivos que pueden ocasionar un error 403, entre ellos:

* Parametros mal encriptados.
* Hash de valores de variables no coinciden

Estos chequeos se hacen por motivos de seguridad para que no se pueda capturar un request, modificar los valores y volver a enviarlo, para lograr hacer que el sistema haga cosas no autorizadas o con valores no validados.

Tambien da error si alguien esta usando la version en Evo3 y presiona un botón y le atiende un servidor en GX16.

Otro motivo es que la persona borre las cookies de su navegador.

Según mi experiencia con migraciones anteriores, varias de estos errores se arreglan modificando la programación, moviendo código a sus eventos correctos, manteniendo el valor en pantalla de algunas variables que se pierden.

Para entender bien lo que está pasando, es necesario habilitar un nivel de trace en DEBUG y ahi salen en el log los valores de las variables que está validando. Con esa información, es relativamente fácil hacer el arreglo.

Hicimos otra instalación con nivel de trace DEBUG, y la aplicación se puso mucho mas lenta, pero nos permitió capturar información valiosa para determinar cuáles eran las principales causas de los problemas.

Vimos que la mayoría de los casos el error se daba en una llamada POST Ajax, que corresponde a llamadas desde la version anterior, en un programa ya cargado.

Que aprendimos en esta etapa

* No es posible habilitar el nivel de DEBUG sin sobrecargar y enlentecer la aplicación (ya lo sabiamos)
* Hay varios motivos de 403. Algunos pueden impedir que el usuario trabaje y otros solo le va a dar el error una vez y luego va a poder trabajar sin problemas.
* La clave que se utiliza para el cálculo de hash de los valores de las variables se guarda encriptada en una cookie llamada GX_SESSION_ID. Si se pierde esa cookie, da error 403.

Continua en Parte 4