Las ultimas semanas he estado notando inestabilidades del browser conocido como chrome o chromium, específicamente en sitios que sirven subconjuntos de java o LJS. (http://www.google.com/#sclient=psy&hl=es&source=hp&q=ljs+java&aq=f&aqi=&aql=&oq=&pbx=1&bav=on.2,or.r_gc.r_pw.&fp=5e1f10055c27afe0)
Uno de los paneles de control de dominios que uso, HSPHERE, tiene una sección mas o menos amplia de control de cuentas, que tiene bastante LJS.
Aunque los problemas de caché de chromium es algo de lo que hablaré después, El origen del problema de momento es por el uso de LJS o java cuando no es necesario.
Vamos por partes:
Javascript muestra información en la computadora del usuario, y no realiza cambios en el servidor.
Los lenguajes como Php, realizan algo en el servidor, y después muestran los resultados en la computadora.
Esto significa que Php carga/cambia cada vez la página , y javascript muestra algo que se cargó una sola vez.
Ajax es una tecnología / metodología que permiite hacer algo en java y pasarlo al servidor. Pero muy pocos sitios avisan si algo no paso al server. Así que podemos ver un «editor» java, donde se capturó datos de un producto o cliente, que se ven como guardados, pero que realmente no existen en el servidor.
Para evitar la recarga de archivos servicios como yahoo han estado sirviendo desde cachés hasta LJS y estandares JSON en lugar de XML. Si bien creo que XML no es seguro, es mucho mejor que JSON.
La principal limitación de JSON es la obligación de hacer un parser adicional (porque no identifica elementos), y si NO sabes hacer un parser como Dios manda, probablemente se acaba ejecutando un eval sobre el conjunto de datos. Resultado, JSON es absolutamente inseguro , o tu haces tu parser espcializado. Si bien el volumen de datos es mas pequeño, es mas ambiguo, hay unos ejemplos claros en http://es.wikipedia.org/wiki/JSON
La mayoría de los servicios JSON o XML que he visto no regresan una hora en formato UTC o de cualquier tipo, asi que no estás seguro si estas viendo o no resultados en caché.
El problema es que muchos grandes proveedores de servicios, están haciendo con JSON los que les da la gana. Hay diversos artículos acerca de como hacer crossforge con JSON (por el problema de rutas predecibles), pero lo que regresan muchos idiotas es «ese JSON está mal implementado porque permite objetos», y no conocen el estandard que dice
http://tools.ietf.org/html/rfc4627
Extracto:
JSON can represent four primitive types (strings, numbers, booleans,
and null) and two structured types (objects and arrays).A string is a sequence of zero or more Unicode characters [UNICODE].
The terms «object» and «array» come from the conventions of
JavaScript.JSON’s design goals were for it to be minimal, portable, textual, and
a subset of JavaScript.
Lo cual significa que tienes dos o tres entradas de datos que no autentifican nada, no guardan nada en server (al ser javascript), o de plano te limitas a un absurdo límite sin objetos de java, que ya no es JSON sino un XML mal diseñado, que no tiene validadores en línea y sin XSLTs.
Creo que a mediano plazo, todas las aplicaciones de seguridad caerán en un modelo mas «xml-rpc», de autentificación pero JSON será para mi un riesgo de seguridad. El colegio que he mencionado antes, tuvo el viernes un problema bastante extraño por unos cachés, que de entrada hubieran llevado a pérdida de datos o respuestas parciales.
Asi que, la solución a corto plazo es:
1 ) Evitar usar jquery
2 ) usar bitácoras via APACHE o similares.
3 ) No usar JSON excepto si XML o XML-rpc no son viables.
La real sería eliminar LJS completammente, o su evaluación de Objetos. El eval es quizá el problema de seguridad mas grande del diseño online, y aunque ne php podemos prohibirlo en nuestro servidor, como el java es por pc, puede hacerse lo que le de la gana… y ser diferente a lo que está en nuestro servidor.
Y en la mayoria de los casos Es mucho mejor usar un FTP o un XML-RPC que JSON.
O que de plano le quiten el manejo de objetos, creo yo.