javascript

Javascript es amor. Javascript NO es JAVA. Javascript no es pariente de JAVA. Javascript se llama así porque cuando estaba dando sus primeros pasos JAVA era el lenguaje de moda, todo esto por allá por 1995, en definitiva todo una cuestión de marketing.

En éste post quería resaltar 2 errores que veo comúnmente, el primero es hacer validaciones del lado del cliente de datos que no deberían ser visibles por un tercero, y el segundo esta relacionado con el acceso al sistema y la carga de librerías que no son estrictamente necesarias, recuerden que el código Javascript puede ser leído fácilmente por el usuario.

No expondrás tu validación al cliente

Ojo, se puede validar, por ejemplo, que el campo para el nombre solo contenga letras, espacios y guiones, ése tipo de validaciones están bien. El problema es cuando se valida un código el cual se obtiene a través de una función que toma datos conocidos por el cliente. La realidad es que esto es malo y no se debe hacer, pero si lo van a hacer, por lo menos no incluyan también el script de validación del lado del cliente.

Ejemplo. El sitio web de un municipio pide el DNI del dueño de una casa, la dirección de ésta y un código de validación para acceder a más datos sobre la misma, datos que solo deberían ser accesibles por el dueño. El código de validación se calcula a través del DNI y la dirección. La función realiza algunas modificaciones al DNI y la dirección y luego algunas cuentas mágicas y devuelve un código, que es el código de validación.

La práctica anterior es cuestionable, no deberían utilizarla si de verdad se preocupan por la confidencialidad de los datos, pero si la utilizan lo peor que pueden hacer es calcular el código de validación del lado del cliente utilizando Javascript, no, por favor, no. Y ojo, Javascript no tiene la culpa.

Incluir Javascript antes de autenticar al usuario

Este error ocurre a menudo, pasa mas o menos así.

1. Un usuario intenta acceder a una función que requiere que éste esté logueado.
2. El sistema muestra la pantalla de logueo.
3. El sistema ya cargó los scripts del área “protegida”.

Esto no siempre está mal, el problema surge cuando los scripts exponen información sobre funciones internas del sistema, por ejemplo, llamadas AJAX a ciertos puntos de la aplicación. El peor escenario ocurre cuando esas URLs no verifican que el usuario esté autenticado y tenga la autorización correspondiente para ejecutar la acción.

Ojo, no está mal cargar librerías/scripts genéricos, como por ejemplo jQuery, pero de todos modos siempre intenten solo incluir lo justo y necesario para que el sitio permita realizar las acciones que corresponden. Y siempre verifiquen que el usuario esté autenticado y autorizado (que tiene el rol adecuado) para ejecutar una acción.

Relacionado con este ultimo punto, también se debe deshabilitar el listado de directorios en el servidor, ya que de nada sirve no incluir los archivos si alguien pueden navegar la estructura de archivos para llegar a ellos.

Conclusión

Si están dando sus primeros pasos en el desarrollo de aplicaciones, o si es la primera vez que van a hacer una aplicación que maneja datos sensibles, o si simplemente les interesa el tema, deberían darse una vuelta por el sitio de OWASP, donde van a encontrar mucha información útil sobre seguridad y buenas practicas para el desarrollo de aplicaciones seguras.

Ya estamos en un tiempo en el que virtualmente todos los navegadores más usados soportan SVG, por lo cual el uso de éste elemento en los sitios web se ha hecho más común, y aún más con la gran cantidad de librerías disponibles para trabajar con SVG hechas en Javascript, siendo D3.js una de las más populares.

Un detalle que pueden haber notado es que para el usuario es a veces un poco complicado descargar un gráfico hecho en SVG, algo que no pasaba con formatos de imágenes como JPG y PNG. Pero afortunadamente, hay una solución a éste problema, y no puede ser más fácil.

Un pequeña muestra

Descargar graficos SVG como PNG

saveSvgAsPng es una librería en Javascript que permite descargar fácilmente gráficos SVG en formato PNG, lo cual es más que interesante y muy útil.

El uso es muy sencillo, es solo cuestión de incluir la librería en el sitio, y llamarla mediante la función saveSvgAsPng, con 3 parámetros, el primero es el elemento SVG, el segundo el nombre del archivo que se genera, y el tercero indica el factor de escala, o sea, el tamaño de la imagen respecto al del SVG.

Lo mejor de todo es que como funciona desde el navegador también pueden abrir cualquier SVG que tengan en su PC y utilizar ésta herramienta para convertirlo a PNG.

Regexper, visualizador de expresiones regulares

Las expresiones regulares son el karma de muchos, pero una vez que las dominamos aprendemos que son una herramienta poderosisima, sobre todo si trabajamos mucho con texto.

Interfaz de Regexper

Regexper es una sitio que nos permite visualizar las expresiones regulares para mejorar la visibilidad y facilitar la tarea de detectar errores. Si bien la herramienta funciona para expresiones regulares en Javascript, la realidad es que dicho lenguaje las hereda de Perl, y a su vez, muchos de los lenguajes modernos también tomaron la sintaxis de las expresiones regulares de Perl, por lo que con probablemente puedan probar las expresiones regulares de otros lenguajes, a lo sumo después de algunos pequeños cambios.

Junto con Regexper pueden utilizar regexpal, que es otra herramienta que nos permite probar expresiones regulares para Javascript, en éste caso debemos ingresar la RE y el texto que deseamos que reconozca.

Un emulador de una PC con Linux programado en Javascript que funciona en el navegador

Verdaderamente no hay mucho mas para decir mas que probar éste emulador creado en Javascript, la intención era mostrar lo avanzado y poderosos que son los motores de éste lenguaje que muchos aún consideran que su única utilidad es crear distintos efectos en las paginas web.

El SO que corre es Linux con el kernel 2.6.20 sobre un procesador x86 de 32 bits.

Para probarlo pueden ingresar a JSLinux, tarda bastante en cargar.

Problemas con Adsense, anuncios en blanco

Hace unos días tuve un problema al actualizar la plantilla de WordPress de éste sitio, los anuncios de Adsense había desaparecido, entre otros problemas que ocurrieron, ¿el responsable? Filezilla, con mi complicidad, obviamente.

¿Como darse cuenta si Filezilla esta haciendo desastres?

Es muy fácil, una vez que hayan subido el theme al directorio correspondiente de WordPress pueden entrar al Editor, seleccionan la plantilla que acaban de subir y se fijan si paso algo con los saltos de linea de los archivos, lo mas común es que hayan desaparecido todos, o si están descargando el archivo con Filezilla a su PC, al abrir el archivo van a descubrir que se agrego un salto de linea por renglón.

Todo ésto se arregla abriendo Filezilla y yendo a “Editar”>>”Configuración” (supongo que es así porque lo tengo en inglés) >>”Transferencias”>>”Tipo de Archivo” y en “Tipo de transferencia predefinida” eligen “Binaria”. En definitiva, tienen que configurar las transferencias para que sean binarias.

Anuncios de Adsense en Blanco

Ahora que ya solucionamos el tema con Filezilla podemos ver bien lo que sucede con Adsense.

Lo fundamental para verificar porque Adsense no funciona es lo siguiente, ver el código de fuente de la pagina, utilizar el debugger del navegador y chequear la configuración de nuestra cuenta.

Primero, hay que tener en cuenta que cuando colocamos un bloque de anuncios por primera vez puede pasar hasta una hora hasta que se vean los anuncios.

Segundo, en ocasiones si hay poco contenido o no se encuentran palabras claves relevantes no se muestran anuncios, ésto se puede modificar desde la cuenta de Adsense, tenemos que ingresar a la configuración del bloque de anuncios y buscar donde dice “Anuncios de reserva”, seleccionan una de las 3 opciones y listo.

Configuracion del bloque de Adsense

Tercero, entrar a la pagina en la que no funcionan los anuncios y ver el código de fuente, fíjense si la estructura del anuncio se respeta, ya que si alguna de las variables de Javascript que posee están en la misma linea que el comentario HTML <!–, dichas variables no van a ser reconocidas. Es muy común en WordPress que funcione un bloque y el otro no, ésto se debe a la forma en la que están creados los themes, ya que puede que uno de los archivos necesarios para el funcionamiento se haya visto afectado y los otros no.

Podemos ver que la request dio un error

Éste error nos percata de que lo que estamos pidiendo no existe, así que el problema esta en el código de nuestros anuncios, para ver si ésto esta ocurriendo solo basta con abrir la consola Javascript del debugger.

Error 400 en el trafico generado por la carga de la web

En la sección de red del debugger vemos como una request da un error 400 mientras que la otra funciona correctamente. Si hacemos clic sobre la request que provoca el error podemos ver el contenido de la misma.

Parámetros del método GET

Si comparamos los parámetros enviados con el de una anuncio que funcione podemos ver que falta algunos, en general el parámetro faltante es el client.

Ahora vemos bien el código HTML de la pagina, yendo a “Ver código de fuente” o CTRL+U.

Error del código del script

Como podemos ver en el código del script una de las variables se encuentra comentada, por lo tanto no funciona el anuncio, ya que al lanzar la request al servidor de Adsense falta uno ó mas parámetros.

Solución

Para solucionar el problema deberían volver a subir la plantilla luego de haber cambiado la configuración de Filezilla, sino la otra opción es directamente eliminar los comentario del código de Adsense.

Si tienen un problema y no lo pueden solucionar dejen un comentario.