Mensaje Error Interno

[rossi.nicolas]

Buenos días,

Tras la instalación de Toba 3.2 y la migración de nuestras aplicaciones a Bootstrap hemos obtenido en algunos casos, y de manera aleatoria el mensaje en pantalla de "Error Interno". Me refiero a que es aleatorio ya que no se de repetidamente y en todos los casos, pero por lo generar ocurre al utilizar Chrome. En el archivo error.log de apache aperece la siguiente línea:

[Wed Sep 18 07:02:17.792180 2019] [php7:notice] [pid 1012] [client 10.101.4.2:46496] toba_error_seguridad: Error Interno Request Invalido\n[TRAZA]\n\t<ul>\n\t<li><strong>toba_nucleo->verificar_pedido_post</strong>
Archivo: /home/administrador/toba/vendor/siu-toba/framework/php/nucleo/toba_nucleo.php, l\xednea 576
\t</li>\n\t<li><strong>toba_nucleo->acceso_web</strong>
Archivo: /home/administrador/toba/proyectos/xxx/www/aplicacion.php, l\xednea 30
\t</li>\n\t</ul>, referer: http:/...........

[richard]

Hola Nicolas,

 respecto del error.. solamente se te da cuando se realiza un POST al servidor, lo interesante seria saber si es aleatorio dentro de la misma operacion siempre o distintas partes del sistema.

Por otro lado, si encontras la manera de replicarlo con mas exactitud seria interesante ver lo que efectivamente envia Chrome como parte del pedido (via herramientas de desarrollo), ya que el error no salta a menos que en el mismo este faltando un campo hidden el cual deberia viajar.

Finalmente, chequearia la configuracion de PHP (en particular post_max_size)  por si justo la operacion involucra la carga de un archivo que pudiera dejar fuera la recepcion de dicho hidden.

Saludos

[rossi.nicolas]

Te paso un fragmento del archivo sistema.log de la instalación:

Fecha: 18-09-2019 08:56:27
Usuario: Elcristiandelagente
Version-PHP: 7.2.19-0ubuntu0.18.04.2
Servidor: xxx.xxx.gov.ar
URI: /xxx/aplicacion.php?ah=st5d821ad230c2d7.98367338&ai=xxx%7C%7C3566
Referrer: http://xxx.xxx.gov.ar/xxx/aplicacion.php?ah=st5d821acdd24101.38658587&ai=xxx%7C%7C3566
Host: 10.101.4.2
==========
[DEBUG][xxx] PUNTO DE MONTAJE: se cargó exitosamente el autoload del punto de montaje proyecto
[DEBUG][xxx] Se intenta hacer un post donde no coinciden parametros anti CSRF
[DEBUG][xxx]  Form: '//Uheju1hiucahESb/voaIFYuaAsWqbZ4CjWy7spEuw='
[CRITICAL][toba] toba_error_seguridad: Error Interno Request Invalido
[TRAZA]
   <ul>
   <li><strong>toba_nucleo->verificar_pedido_post</strong>
Archivo: /home/administrador/toba/vendor/siu-toba/framework/php/nucleo/toba_nucleo.php, línea 576
   </li>
   <li><strong>toba_nucleo->acceso_web</strong>
Archivo: /home/administrador/toba/proyectos/xxx/www/aplicacion.php, línea 30
   </li>
   </ul>

[richard]

Hola Nicolas,

bien, por lo que veo el browser esta enviando el hidden... la pregunta entonces es, por que no coincide el valor que esta almacenado en sesion con el valor enviado por el formulario?.
Podes describirme un poco la operacion?, tiene algun popup?.

(btw te edite el msg para eliminar el usr, era dato sensible)

Saludos

[rossi.nicolas]

Por ejemplo, la siguiente pantalla siempre tira error en mi PC pero en la de la oficina no, y la verdad es mus sencilla, el error es al momento de Filtrar.

[richard]

Hola Nicolas,

Por ejemplo, la siguiente pantalla siempre tira error en mi PC pero en la de la oficina no, y la verdad es mus sencilla, el error es al momento de Filtrar.

como bien decis la operacion es muy sencilla para que falle y por lo que me pasaste en el post anterior,  del log saco que el valor en efecto esta llegando al server (salvo que en este caso no sea asi? fijate eso).

Si falla en dicho caso, no hay muchas opciones:

- Se esta perdiendo el valor que esta en sesion, lo que implicaria que perdes parte de la sesion.
- Hay algun pedido intermedio que modifica el valor almacenado en sesion y luego no coincide con el enviado por la aplicacion al filtrar.

Te paso que en algun momento la aplicacion te envie nuevamente al login?.. seria un claro sintoma del primer caso.
La segunda opcion es mas facil de detectar, mirando el access log del web server podes determinar si hay algun pedido de pagina extra entre la llegada al cliente y el lanzado del evento al presionar Filtrar.

Finalmente, si es algo que pasa en tu PC... haria un diff de la configuracion de PHP entre la maquina de la oficina y la tuya... configuradas igual, no hay motivo para que se comporten de maneras diferentes.

Saludos

[obelgran]

Hola Comunidad!

Estoy con un problema muy parecido al de Nicolás:

Tengo un proyecto hecho con toba 2.7.6 que tiene un filtro con varios campos: un combo editable en cascada con otros dos combos dependientes y un campo más totalmente independiente.

Bien, cuando filtro por el campo independiente todo va bien.
Cuando uso el combo editable se produce el error
 

Se intenta hacer un post donde no coinciden parametros anti CSRF
Form: 'Vz2/+ziag0OpoBpmgy1ff9pcawrlYOeogsvTSaB1WDA='

Verifique el campo  id='cstoken' antes y después de cargar el combo editable y es el mismo.
No hay errores en la consola de javascript.

Qué otra cosa podria ser ??

Gracias y saludos.

Oscar

[richard]

Hola Oscar,

como le decia a Nicolas, las situaciones por las que se dispara el control son pocas... la mas sencilla de verificar es si hay algun pedido POST intermedio que no deberia estar y que este cambiando el token.

Asumo que tenes por ahi toba_referencia,  tiene una operacion de formulario con un combo_editable.. fijate si te esta generando el mismo inconveniente por favor, al menos con eso podemos descartar algo de la operacion puntualmente.

Lo otro que podrias mirar (usando las herramientas de debug del browser) es si el pedido del combo_editable para buscar coincidencias... lleva la marca de menu incorporada (osea un parametro "tm=1")  que podria ser la otra causa de que se resetee el estado del token.

Finalmente, la unica opcion que quedaria (y la mas complicada de ver) es que la comparacion falle y PHP entienda que son strings distintos.

Saludos

[obelgran]

Richard:

Ayer tenía el problema en el servidor de desarrollo y en el de producción, hoy no se produce en ninguno de los dos.
Espero que no vuelva a pasar, cualquier cosa te consulto nuevamente.
Gracias por tu pronta respuesta.
Saludos
Oscar

[richard]

Hola Oscar,

Ayer tenía el problema en el servidor de desarrollo y en el de producción, hoy no se produce en ninguno de los dos.
Espero que no vuelva a pasar, cualquier cosa te consulto nuevamente.

te puedo pedir un favor?.. tenes a mano los logs de ambos lugares? como para sacar que tokens fueron los que fallaron,  a ver si hay algun patron entre ellos.
Cuando algo se rompe y se arregla solo, o es un error involuntario (la mayoria de las veces) ... o es algo muy rebuscado que depende de algun factor oscuro en PHP.
Mirando la fecha del hilo de Nicolas.. veo que es mas o menos hace un año, eso  (aunque suene conspiranoico) es algo raro.

Si podes extraerme los tokens csrf que aparecen o sino si me pasas los archivos (matale el pwd de postgres con un SED), miro y busco a ver si hay alguna razon por la que la libreria pudiera estar generando una secuencia puntual de identificadores que esten fallando, asi como no tiene que dejar pasar pedidos invalidos.. tampoco tiene que marcar mal.

Saludos

[obelgran]

Hola Richard, te paso los logs de ambos sistemas, el error lo empezó a dar en ambos sistemas simultáneamente y tambien dejó de darlos al mismo tiempo, no se si la fecha puede estar relacionada o no pero parece que así fuera...

Saludos
Oscar

[richard]

Hola Oscar,

gracias por los archivos ... si tengo alguna novedad te aviso.

Saludos

[seula]

Hola como están. Vi estos mensajes del foro y me pregunto si encontraron como solucionarlo. Me ocurre lo mismo en un proyecto toba 3.3.21, lo raro es que cuando uso el usuario toba no me ocurre.
Alguna Idea?

Muchas Gracias!!!!

[richard]

Hola Sebastian,

Hola como están. Vi estos mensajes del foro y me pregunto si encontraron como solucionarlo. Me ocurre lo mismo en un proyecto toba 3.3.21, lo raro es que cuando uso el usuario toba no me ocurre.
Alguna Idea?

habria que ver puntualmente el caso, en los logs que me paso Oscar por ejemplo hubo algun caso disparado por uso particular creo y otros que no tenian explicacion, sin embargo no pude distinguir un patron raro en la generacion de los tokens tampoco.

En las pruebas locales que hice (por si habia valores extraños en esos datos) las comparaciones entre strings dieron bien siempre que lo enviado por el cliente coincidia con lo que existia en sesion, por lo que descarte algun efecto oscuro de PHP.

Lo que me planteas del usuario administrador se sumaria a lo inexplicable (a priori) de confirmarse ya que no hay caso particular alguno para dicho usuario y lo unico que lo diferencia de otros son los permisos de acceso a las operaciones.

Salvo que este habiendo alguna excepcion (por permisos) que modifique el curso de la solicitud sin terminarla (lo que seria extraño), se alcance a generar un nuevo token y se envie al cliente pero no se almacene en session, no se me ocurre otra explicacion... y los errores de permisos liquidan todo apenas empieza el pedido de pagina.

Es algo que se me viene escapando, lo unico que puedo hacer es revisar los logs para ver si puedo sumar detalles que me lleven a la causa y asi solucionarlo.

Saludos