Fotografía Juan Díez-Yanguas » Informática

Spotbros: Un ejemplo de como hacer las cosas bien

Juan — Tue, 21 Feb 2012 10:38:48 +0000

Esta semana pasada navegando por una de mis webs sobre Android me encontré con una nueva aplicación al estilo Whatsapp, pero bien distinta; el artículo me convenció y decidí probarla y la sorpresa ha sido tan agradable que aquí estoy escribiendo un artículo sobre ella.

La aplicación se llama Spotbros, es nueva, acaba de salir en enero y está en versión beta; se trata de una aplicación de mensajería instantánea vía internet por push al estilo de Whatsapp, pero seguro, bien hecho y encima con unas ideas añadidas bastante interesantes e innovadoras.

Convendría comentar que no estaría escribiendo esto sino me hubiera llamado tan gratamente la atención en muchos aspectos, comencemos describiendo la aplicación.

Como he dicho no es algo nuevo, ya existe, lo tenemos, pero… ¿lo que tenemos es lo mejor? Yo diría que no, entre funcionamiento, fiabilidad, calidad y seguridad hay diferencias; muchas veces parece que importa más el que primero saca la idea que el que saca la idea con mejor calidad.

Pues si es algo que ya tenemos habrá que ver las diferencias ¿no?. Pues vamos a ello; en primer lugar es seguro, todas las comunicaciones son encriptadas usando AES de 256 bits, uno de los algoritmos de encriptación más seguros que hay. Mayor privacidad, todo rastro de nuestras conversaciones es borrado de sus servidores a los 30 días y nadie nos puede hablar sino le conocemos, es necesario que los dos extremos de la comunicación tengan al otro usuario en la agenda. Mayor eficiencia y fiabilidad, a pesar de estar en beta he notado una aplicación muy fluida y sin ningún cuelgue, e incluso he notado menor consumo de batería que con otros servicios.

Y además, no solo han mejorado lo existente por mucho sino que han añadido nuevas funcionabilidades bajo mi punto de vista interesantes e innovadoras.

Veamos que cosas son las que han introducido como nuevas.

En primer lugar, se permiten grupos, pero… ¿solo grupos? Pues no, tiene la opción de los grupos tradicional y una nueva forma de grupo bajo el nombre de spots. Grupos asignados a un lugar, se pueden crear y unir a ellos, y se muestran los que hay a tu alrededor, una forma de añadir a la aplicación funciones sociales que pueden ser muy útiles.

Y finalmente, un añadido más, ellos lo llaman shouts, pero se podría llamar un mensaje de broadcast, o un mensaje a todo el mundo; esta función manda un mensaje a todos en un radio de 1.5km. Sin duda algo muy interesante para poder mandar comunicaciones a tu alrededor, y podría ser de mucha ayuda ante una emergencia por ejemplo. Algunos podrán pensar que esto puede ser un medio de spam, pero lo cierto es que los chicos de Spotbros lo saben y tienen en mente numerosas ideas interesantes para evitar esto.

También han mejorado lo ya existente en el envío de mensajes, en concreto en lo que se refiere a los mensajes multimedia. Permiten enviar varias imágenes en un mismo mensaje; y lo que ahora son fotos en próximas versiones serán fotos, vídeos, audio y mapas todo ello en un mismo mensaje. No cabe duda de que lo que tenemos ante nuestros ojos es una obra de la innovación que en este caso va de la mano con la calidad.

Bueno, y por terminar comentar algo acerca del soporte, no he visto soporte igual en mucho tiempo, respuesta en poco tiempo, una respuesta personalizada, simpática, interesándose por un problema, muy educados, y además eficientes.

La aplicación de momento está disponible para android y para iphone está en desarrollo; de manera que también es multiplataforma.

Bueno, finalmente hacer notar que esto no es un artículo patrocinado ni nada que se le parezca, simplemente he probado la aplicación, me ha dado una muy grata sorpresa y creo que tiene mucho potencial detrás, y de ahí que este escribiendo este artículo.

Lo malo: todavía, como es normal no lo tiene mucha gente, pero creo sinceramente que con este potencial puede llegar muy lejos, solo necesitan nuestra ayuda para crecer poco a poco.

NOTA: Las imágenes del artículo son propiedad de Spotbros Technologies S.L.

Artículos más comentados

JRebel: Stop Redeploying

Juan — Sat, 18 Feb 2012 12:18:11 +0000

Esta semana que se va ha sido el SpringI/O en la Universidad San Pablo CEU, mi universidad. Mi función en este evento ha sido básicamente ayudar en lo que he podido, lo que no quita que haya podido ver cosas realmente interesantes, y entre ellas de la que hoy os voy a hablar: JRebel & LiveRebel.

Ambos productos de la empresa ZeroTurnaroud proveniente de Estonia. Tienen como idea principal facilitar al desarrollador de aplicaciones web la tediosa tarea de guardar, para el servidor y redesplegar. Ahora estas tareas se harán de manera totalmente transparente a nosotros. Veamos la idea principal de ambos productos.

JRebel: Para desarrolladores

El la idea final del producto es ayudar a los desarrolladores Java EE y ahorrarles tiempo en tareas tediosas que se dan en este entorno. Esto es, cada vez que hacemos cambios en una aplicación hay que guardar los cambios, parar la aplicación y redesplegar la aplicación de nuevo en el servidor de aplicaciones.

Aunque este problema este medianamente solucionado por lo menos en NetBeans que sí permite realizar estas acciones en caliente la solución no funciona para todos los tipos de cambios.

Y aquí es donde entra JRebel, el cual realiza estas tareas para tí de manera automática y transparente, y no solo eso sino que admite todo tipo de cambios (los podemos ver en su web). Y no solo eso, sino que soporta los principales IDEs (NetBeans, Eclipse… ) y servidores de aplicaciones (GlassFish, Tomcat, SpringSource, JBoss …).

Hoy nos han hecho una demo a varios compañeros y a mí y he de decir que funciona realmente bien. Me parece una herramienta realmente útil para desarrolladores.

El inconveniente: Es de pago, aunque hay varias versiones dependiendo de las características con precios diferentes; y también una versión gratuita para usos no comerciales. Y algo realmente interesante es la posibilidad de probar gratuitamente la versión completa durante 30 días.

LiveRebel: En producción

La idea de este producto es algo más complicada, orientada a las aplicaciones en producción y con un público más reducido.

Se trata de extender la idea de JRebel a un entorno de producción permitiendo principalmente actualización de las aplicaciones en caliente; la idea es retener las peticiones al servidor mientras la nueva versión de la aplicación es desplegada en el servidor y posteriormente pasar las peticiones al servidor como si nada hubiera ocurrido.

Tiene también otra serie de funciones como la comparación de versiones, integración contínua …, aunque sin duda alguna la más interesante de ellas me ha parecido la primera. No obstante, hoy se debatía entre los que estábamos viendo la demo la utilidad real de este proyecto, ya que, al fin y al cabo la mayoría de las veces no es un gran inconveniente parar el servidor por un corto periodo de tiempo para actualizar la aplicación web.

Esta herramienta como era de esperar tampoco es gratuita, y también consta de varias versiones con varios precios dependiendo de las características. Tiene disponible una evaluación de 90 días.

En resumen, JRebel me parece una fantástica herramienta que puede ayudar a muchísimos desarrolladores y ahorrarles mucho tiempo en el desarrollo de aplicaciones web.

He de recalcar que este artículo no es ningún tipo de patrocinio, se ha escrito porque vi la demo y lo que me contaron y me ha parecido que debería darse a conocer en más idiomas.

NOTA: Las imágenes son propiedad de ZeroTurnaround.

Vanadium: Validación de formularios con JQuery

Juan — Wed, 01 Feb 2012 09:05:13 +0000

Recientemente he anunciado en el blog por medio de una pequeña anotación que había sido subsanado uno de los problemas que tenía la tienda online en Java EE. La tienda había sido dotada de un mecanismo para validar en el registro si un email estaba ocupado o no, pero esta función no llegó a funcionar (aunque sí estaba implementada) por razones que hasta hace poco desconocía.

Dicho esto, creo que una vez solucionado este problema podría ser un buen momento para que os hablara en profundidad de las validaciones realizadas en los formularios de la tienda en el lado del cliente.

Creo que sería una buena manera de empezar siendo sinceros y comentando que no soy ni un experto en JavaScript ni en JQuery, sin embargo si he aprendido a realizar la tarea que os voy a mostrar hoy a base de investigar bastante sobre el asunto concreto que esta vez nos atañe y de luchar para que aquello funcionara correctamente.

Cuando me dispuse a realizar las validaciones de la tienda online lo primero que busqué fue una solución rápida al problema, recordemos que se trataba en un principio de una práctica, y como tal, con una fecha de entrega; así que, lo que hice fue buscar alguna librería de JQuery que me solucionara el problema. Al realizar la búsqueda mi primer resultado fue Vanadium, y esa fue la que usé y la que os voy a explicar hoy aquí. Lo que, no quita que no haya otras librerías de validación.

Respecto a la librería que yo he utilizado llamada VanadiumJS cabe destacar la sencillez de su configuración además de que es fácilmente personalizable para adaptarla a nuestras necesidades. Vamos a ver como funciona.

Instalación

Para empezar, lo primero que haremos es explicar como hemos de configurar la librería e instalarla. Una buena manera de empezar sería crear un directorio en nuestra aplicación web para guardar archivos JavaScript. Y, en dicha carpeta tendríamos que guardar en primer lugar la librería de JQuery que podemos encontrar en su web y, después guardaríamos en ese mismo directorio la librería que vamos a usar que también la podeis descargar de la misma web de VanadiumJS.

Es importante colocar estas dos librerías de JavaScript debido a que Vanadium como era de esperar hace uso de JQuery.

Posteriormente, también deberíamos crear una carpeta para guardar hojas de estilos css, aunque posiblemente ya la hayamos creado para guardar nuestras propias hojas de estilos. Dentro de esta carpeta deberemos colocar una hoja de estilos como esta. Los estilos de esta hoja son los que serán aplicados a los formularios en caso de validación correcta o validación fallida.

Es una hoja de estilos sencilla de personalizar puesto que los nombres que llevan cada uno de los estilos son bastante intuitivos.

Finalmente toca hacer funcionar esto dentro de nuestros ficheros html estáticos o jsp u otros lenguajes. Esto será tan sencillo como importar todos estos archivos que hemos usado en la cabecera de cada fichero en la que lo queramos usar. Si esto nos resulta incómodo en el caso de jsp siempre podríamos hacer uso de la etiqueta import para no tener que poner estas líneas en todos los ficheros en los que se use.


	
	Login

Validación en formularios

En este apartado aprenderemos a llamar a esta librería para que haga las validaciones pertinentes en cada campo del formulario.

Vanadium usa el atributo class de los elementos de los formularios para que en él se escriban los ajustes que sean necesarios. Veamos un ejemplo sencillo con el que se validaría un campo de texto en el que se espera un e-mail.

Se puede observar que hay un símbolo de dos puntos (:) al principio de cada ajuste. En este caso estaríamos indicando que se realizara una validación según la expresión regular de un email. Si hacemos la prueba de este código veremos que realiza la validación por cada evento que ocurre en la caja de texto, si no queremos este comportamiento se puede cambiar para que lo realice pasado un tiempo después de un evento o para que lo realice sólo cuando el campo se abandone (terminar de escribir y pasar al siguiente campo).

Otro aspecto importante es que en el ejemplo anterior se podría no escribir nada en la caja de texto y pasar la validación sin problemas, si se quiere que esto sea un campo requerido habría que usar otro ajuste. Veamos ahora un ejemplo más complejo.

NOTA: En los códigos hay un espacio sobrante entre los dos puntos (:) y la o de “only_on_blur” debido a que se cambiaba por su correspondiente emoticono.

También es posible la validación de otro tipo de campos a parte de el email que va vienen implementados por defecto con la librería. Podemos encontrar en la página web del proyecto una lista de las posibilidades admitidas. Todos los ajustes que necesiten de un valor se indicará con el punto y coma (;) y después el valor, como se ha visto para el caso de wait.

Veamos por ejemplo como validar un campo típico en el que se pide que repitas la contraseña, para comprobar que has escrito lo mismo en los dos lugares.

Contraseña



Reescriba la contraseña por seguridad

Personalizar los mensajes de error

Puesto que es una librería escrita en inglés es de suponer que los mensajes de error que se produzcan cuando falle la validación esten en inglés, pero no hay problema, lo podemos cambiar. Para ello deberemos abrir el fichero JavaScript de Vanadium que hemos guardado en la carpeta de scripts, y luego nos dirigiremos a la línea 1012 aproximadamente.

Podremos ver estructuras repetitivas que llevan la expresión regular con la que se ha de validar, un nombre y un mensaje de error. Mostremos una de ejemplo.

['asciialpha', function (v) {
	return Vanadium.validators_types['empty'].test(v) || /^[a-zA-Z]+$/.test(v)   //% C0 - FF (� - �); 100 - 17E (? - ?); 391 - 3D6 (? - ?)
}, 'Please use ASCII letters only (a-z) in this field.'],

Ahora si lo que queremos es que el mensaje se muestre en español sería tan sencillo como traducir el mensaje.

['asciialpha', function (v) {
	return Vanadium.validators_types['empty'].test(v) || /^[a-zA-Z]+$/.test(v)   //% C0 - FF (� - �); 100 - 17E (? - ?); 391 - 3D6 (? - ?)
}, 'Por favor, use solo caracteres ASCII (a-z) en este campo'],

Como podemos ver es una tarea bastante sencilla.

Personalizar los tipos de validaciones

En este apartado veremos que también es posible añadir otros tipos de validaciones aparte de las que ya vienen implementadas por defecto con la librería, por ejemplo sería interesante una validación para direcciones postales.

Para esto nos situaremos en la zona del fichero JavaScript de Vanadium, aproximadamente por la línea 1012 y solo tendremos que repetir la estructura que ya hemos comentado en el apartado anterior pero personalizándola según nuestras necesidades. Mostraremos un ejemplo para validar una dirección de email; como se puede ver bastará con adaptar una expresión regular y personalizar nuestro mensaje.

['dir', function (v) {
	return Vanadium.validators_types['empty'].test(v) || /^[a-zA-Z0-9 \,\º\-\u00C0-\u00FF\u0100-\u017E\u0391-\u03D6]+\ [0-9]{5}-[a-zA-Z \-\u00C0-\u00FF\u0100-\u017E\u0391-\u03D6]+$/.test(v)   //% C0 - FF (� - �); 100 - 17E (? - ?); 391 - 3D6 (? - ?)
}, 'Introduzca una dirección válida'],

Y posteriormente, en los formularios, bastará con usar el nombre que se le ha dado a la validación, en este caso ‘dir’.

También se pueden hacer cosas más complejas como se puede ver en líneas inferiores siguiendo la misma estructura.

Validación usando la lógica del servidor por medio de AJAX y JSON

En ocasiones no se pueden realizar todas las validaciones por medio del cliente, a veces se necesitan datos que solo se pueden obtener del servidor. El típico ejemplo de esto sería comprobar si una dirección de email ha sido ya usada anteriormente o no. Para este tipo de validaciones lo que se suele hacer es usar AJAX para realizar peticiones al servidor.

En el caso concreto de Vanadium nos va a permitir realizar una petición AJAX a la dirección que deseemos y el esperará un objeto JSON como respuesta a dicha petición que indique si la validación ha sido correcta o no.

Lo primero que haremos será preparar un Servlet Java EE preparado para recibir peticiones en un determinado patrón de url personalizando este ajuste en el descriptor de despliegue.


    CheckEmailServlet
    control.CheckEmailServlet


    CheckEmailServlet
    /checkmail

Posteriormente en la implementación del Servlet lo primero que haremos es definir el tipo de respuesta como un objeto JSON y posteriormente abriremos el flujo de salida en el que escribiremos el JSON que espera Vanadium, que será como este que podemos observar en la web del proyecto. Como vemos primero se indica si la validación fue válida y posteriormente un mensaje para mostrar en caso de error en la validación.

{
  success: true,
  message: "The username is free."
}

mostremos ahora el código de un servlet sencillo que siempre devolverá la misma respuesta. Por supuesto hay que tener en cuenta que las escrituras en el flujo de salida deberían de ir en un try y realizar el cierre de la misma en un bloque finally. Como se puede observar simplemente se va construyendo el objeto JSON en el flujo de salida. Este Servlet en realidad no hace nada pero sería tan sencillo como devolver una u otra respuesta dependiendo de ciertas condiciones; que en nuestro ejemplo concreto sería comprobar si una dirección de email está usada o no.

response.setContentType("application/x-json;charset=UTF-8");
PrintWriter out = response.getWriter();
out.println ("{");
out.println("\"success\": false,");
out.println("\"message\": \"Dirección de email no disponible\"");
out.println("}");
out.close();

Ahora habrá que configurar el campo del formulario que se desea validar al estilo de como se ha hecho en los ejemplos anteriores. Habrá que usar la opción ajax y después del punto y coma (;) habrá que indicar la dirección a la que se quiere realizar la petición. Veamos el ejemplo concreto.

Como vemos la directiva es bastante sencilla, simplemente se indica que se quiere hacer una validación vía AJAX y la dirección a la que se quiere hacer la petición, y como vemos es perfectamente combinable con cualquiera de las opciones ya vistas en apartados anteriores.

Pues hasta aquí con este tutorial sobre el uso de la librería Vanadium para realizar validaciones de formularios en el lado del cliente usando JavaScript y JQuery. Comentar también que en la misma página de Vanadium es posible encontrar más ejemplos.

Espero que os haya sido útil este tutorial y mi parte nada más que decir; solamente deciros como siempre que están los comentarios a vuestra entera disposición para cualquier duda o sugerencia.

Tienda Online Java EE: Solucionada validación ajax en formulario de registro

Juan — Fri, 13 Jan 2012 20:46:11 +0000

Para todos aquellos que no lo sepan, en este blog fue publicado hace tiempo un ejemplo de Java EE, una tienda online, pues bien, hoy vamos a comentar una pequeña actualización.

Seguramente los que ya han usado el ejemplo y visto la documentación se habrán dado cuenta que la validación del lado del servidor usando ajax y JSON para comprobar en el registro que el email no estuviera en uso no funcionaba, como bien deje notificado.

Pues bien, después de tiempo intentando diversas cosas y mirando documentación del autor, ahora después de los examenes de enero he dado con el problema y lo he solucionado, la solución ha sido debidamente actualizada en el control de versiones y está disponible al público.

Más adelante explicaré detalladamente el tema de las validaciones con JavaScript en el cliente para que todos sepamos como han sido implementadas.

También, como sabéis el artículo fue publicado tambien en Javahispano, comentar que para mi asombro, el artículo ha salido entre los 10 más populares de 2011.

Espero que os haya gustado la notica, personalmente estoy contento porque es un tema que me ha traído bastante de cabeza.

Java EE: Seguridad en aplicaciones web (II). Evitando Inyección SQL y XSS con ESAPI

Juan — Tue, 13 Dec 2011 18:04:56 +0000

Después de un tiempo un poco más atareado por fin encuentro un hueco para cumplir mi promesa, vamos a continuar la guía de seguridad en aplicaciones web que se inició hace un tiempo. En esta nueva entrada se cubrirán en detalle los aspectos que quedaron por cubrir en la primera entrega: Inyección SQL y Cross Site Scripting (XSS). Aprenderemos a usar la librería ESAPI para evitar estos problemas de seguridad.

Inyección SQL

Comenzaremos hablando por el primero de los riesgos de seguridad que se comentaban en la entrada anterior. Para hacer un breve recordatorio veíamos que se trataba de intentar comprometer de alguna manera la base de datos de la aplicación.

Para ello, se suelen usar los formularios de las páginas web tratando de cerrar en ellos una consulta SQL e iniciando otra a continuación; dicho esto enviar directamente los datos de los formularios hacia una consulta SQL no es una buena práctica. Veremos en este apartado una serie de buenas prácticas que deberíamos llevar a cabo para evitar la inyección SQL.

Uso de PreparedStatements

En primer lugar una muy buena práctica es cambiar el uso de los Statements por los PreparedStatements. Este tipo de Statement obliga a que la consulta tenga exactamente la estructura que se indica, y no deja que se cambie la estructura de la misma o se cierre una consulta y se abra otra nueva. También lleva a cabo un escapado de caracteres, puesto que podrías poner de nombre “O’Donnell” y no habría problema alguno en poner la comilla simple. Ni que decir tiene que también podríamos evitar la inyección SQL usando procedimientos almacenados.

Para hacer una consulta con un PreparedStatement lo primero que se hace es indicar la estructura de la consulta dejando los parámetros marcados con una interrogación “?” y posteriormente se irá indicando que son cada una de esas interrogaciones y su tipo de dato. Y gracias a que se indica el tipo de dato, Java ya se encarga de poner las comillas que hagan falta dependiendo del tipo de dato. Veremos que hay muchos métodos set dependiendo del tipo de dato a introducir.

Veamos un ejemplo. En el ejemplo se muestra un método sencillo para hacer un insert en la base de datos . He puesto el método completo para que también se observe una buena estructura para un método de este tipo. Siguiendo esta estructura es la mejor manera de asegurarse de que todos los recursos van a ser liberados en cualquier caso, tanto si se produce un error como si la ejecución es normal. Voy a explicar al final de esta entrada en que consiste ese método cerrarConexionYStatement (), ya que considero que es un punto importante a tener en cuenta para ahorrarnos unas cuantas líneas de código.

public boolean addUser(Usuario user) {
    Connection conexion = null;
    boolean exito = false;
    PreparedStatement insert = null;
    try {
        conexion = pool.getConnection();
		//Definir la estructura de la consulta
        insert = conexion.prepareStatement("INSERT INTO " + nameBD + ".Usuarios VALUES (?,?,?,?,?)");
		//Indicamos cada uno de los parámetros
        insert.setString(1, user.getMail());
        insert.setString(2, user.getNombre());
        insert.setString(3, user.getDir());
        insert.setString(4, user.getPass());
		//Incluso si no encontramos un método set para incluir un tipo de dato se puede personalizar como en este caso
        insert.setObject(5, user.getPermisos(), java.sql.Types.CHAR, 1);

        int filasAfectadas = insert.executeUpdate();
        if (filasAfectadas == 1) {
            exito = true;
        }
    } catch (SQLException ex) {
        logger.log(Level.SEVERE, "Error insertando usuario", ex);
    } finally {
        cerrarConexionYStatement(conexion, insert);
    }
    return exito;
}

En el código de la tienda online podemos encontrar numerosos métodos de este estilo y se pueden ver ejemplos en los que se use un ResultSet e incluso algún ejemplo en el que se realizan varias transacciones dependientes entre si y se realizan rollbacks y commits manualmente.

Hay que comentar que aunque no se vea siempre se realizan commits en todos los métodos, solo que por el hecho de ser consultas simples la conexión realiza los commit de manera automática, pero esto se puede cambiar como se puede ver en el código de la tienda online.

conexion.setAutoCommit(false);

Realizar validaciones con expresiones regulares

¿Esto es todo lo que podemos hacer? Pues no, podemos usar como medida de apoyo una validación de todos los datos de entrada de los usuarios en los formularios. Para realizar esta validación usaremos la librería que nos proporciona OWASP que se hace denominar ESAPI.

Y ahora como es lógico veremos como usar esta librería y configurarla. En primer lugar hemos de bajar el paquete que nos proporcionan en el que se incluye en jar de ESAPI y todas las librerías que requiere ESAPI para funcionar (carpeta libs del paquete descargado). Hemos de añadir todas esas librerías a nuestro proyecto.

Una cosa importante. Entre las librerías requeridas es posible que se incluya la librería de servlets. Esa librería no la debéis de incluir en el proyecto puesto que es una versión más antigua de los Servlets y cambian métodos como por ejemplo la forma de acceder al contexto de la aplicación, por lo que nos interesa conservar la especificación de Servlets moderna que tenga nuestro servidor de aplicaciones.

La siguiente parte importante son los ficheros de configuración que necesita ESAPI para funcionar: ESAPI.properties y validation.properties. Podemos encontrar una plantilla de cada uno de los ficheros en el paquete descargado en configuration/.esapi.

La siguiente tarea es colocar los ficheros de configuración en un lugar adecuado para que se reconozcan. ESAPI buscará los ficheros en varios lugares en el orden en el que indico a continuación. Encontraremos esta información en la página de ESAPI o de la manera que lo he hecho yo que es mirando la consola del servidor de aplicaciones

INFO: Not found in 'org.owasp.esapi.resources' directory or file not readable: /Applications/NetBeans/glassfish-3.1/glassfish/domains/domain1/ESAPI.properties
INFO: Not found in SystemResource Directory/resourceDirectory: .esapi/ESAPI.properties
INFO: Not found in 'user.home' (/Users/Usuario) directory: /Users/Usuario/esapi/ESAPI.properties
INFO: Attempting to load ESAPI.properties via the classpath.

En mi caso me pareció lo más cómodo incluirlo en el classpath. Para ello cree en la raiz del proyecto una carpeta llamada setup, que por otra parte es estándar que los proyectos web puedan tener esta carpeta para archivos de configuraciones, y posteriormente se ha de añadir dicha carpeta al classpath del proyecto.

Una vez que hemos colocado los archivos en su lugar comenzaremos configurando cada uno de ellos. Lo que se va a configurar en estos ficheros principalmente serán las expresiones regulares que se van a usar para validar cada uno de los campos que deseemos.

El primer fichero que hemos nombrado, ESAPI.properties es un fichero que en lo que a nosotros nos concierne no hemos de tocar nada, la librería se sirve de él para hacer sus operaciones; nuestras personalizaciones irán en el segundo fichero nombrado. Pero no está de más echar un ojo al fichero para ver las validaciones que ya incluye y se verá que incluye validación para Email y alguna otra cosa más. Mirándolo también veremos cual es la forma de las expresiones regulares que admite.

Ahora pasemos al segundo fichero en el que hemos de configurar las expresiones regulares que consideremos necesarias. Para ello hemos de poner una clave y una atributo; al estilo de un fichero de propiedades. La clave será siempre Validator.Campo, siendo Campo lo que usaremos posteriormente para referirnos a esa expresión regular.

Esto no pretende ser un tutorial sobre como crear expresiones regulares, sin embargo haré algunas anotaciones. Si alguien necesita más ayuda con el tema puede preguntar y no tendré problema alguno en resolver sus dudas.

El símbolo “^” indica el inicio de la cadena, mientras que el símbolo “$” indica el final de la cadena. Es bueno escapar caracteres como el guión y el punto puesto que el guión se usa para indicar un rango y el punto significa cualquier cosa. Otra anotación importante es que a la hora de poner caracteres regionales debéis ponerlos con su correspondiente código en UTF-16; si no se hace de esta manera después puede que no funcione correctamente. Se puede encontrar una tabla de correspondencia básica en la wikipedia. Por ejemplo, si se quiere poner una ‘a’ acentuada “á” se debe poner así \u00e1.

Si tenéis problemas con las expresiones regulares hay una web que podéis usar que puede resultar interesante. También se puede usar un software específico para expresiones regulares que nos puede ayudar a crearlas en unos sencillos pasos y también nos ayudará a crearlas. Su nombre es RegexBuddy y RegexMagic. El primero de ellos es sobretodo para aprender y verificar expresiones regulares mientras que el segundo está orientado a su creación.

Veamos ahora un pequeño ejemplo que son las que usé yo para la tienda online. Decir que no hace falta crear expresiones regulares para números porque tiene su verificación a parte que ya veremos.

Validator.Pss=^[A-Za-z0-9._$%&/()= -#@áÁéÉíÍóÓúÚüÜñÑ]+$
Validator.Name=^[A-Z][a-zA-Z -áÁéÉíÍóÓúÚüÜñÑ]+$
Validator.Adress=^[A-Z][a-zA-Z0-9\-\ \,ºáÁéÉíÍóÓúÚüÜñÑ]+\ [0-9]{5}\-[A-Z][A-Za-z\ \-áÁéÉíÍóÓúÚüÜñÑ]+$
Validator.NameDescProd=^[A-Za-z0-9.,-_ @#%&=áÁéÉíÍóÓúÚüÜñÑ¿?¡!]+$

Una vez que estos ficheros han quedado correctamente configurados pasaremos ha explicar como han de usarse dentro de nuestra aplicación.

Veamos por ejemplo un método para validar un nombre usando la expresión regular que hicimos para validar un nombre. He dejado comentados cada uno de los argumentos necesarios y también se encuentra disponible el javadoc en la página de los repositorios del proyecto o en el paquete descargado; por ejemplo puede existir un argumento más para que la cadena de caracteres se pase a forma canónica antes de ser validada.

public static String validateName(String input) throws IntrusionException, ValidationException {
    Validator validador = ESAPI.validator();
	//Nombre a referirse, entrada, nombre de la expresión regular, máxima longitud, permitir nulo o no
    return validador.getValidInput("Nombre", input, "Name", 100, false);
}

El método devuelve la cadena validada y en caso de error hay dos tipos de excepciones, ValidationException es lanzada cuando simplemente no se ha pasado la validación, mientras que IntrusionException se lanza cuando se cree de manera muy clara que ha ocurrido un intento de ataque.

El primer argumento es un nombre para nuestro uso personal que posteriormente lo usará si hay un error para indicar donde ha ocurrido. Y el nombre de la expresión regular ha de ser el mismo que dimos en el fichero de propiedades, de esta manera se elige con que expresión regular se desea validar una entrada.

Como dije no hace falta crear expresiones regulares para los números puesto que usan validaciones a parte. Veamos un ejemplo.

public static int validateNumber(String input) throws IntrusionException, ValidationException {
    Validator validador = ESAPI.validator();
	//Nombe para referirse, entrada, mínimo, máximo, permitir nulo o no
    return validador.getValidInteger("Entero", input, 0, 999999, false);
}

Como se puede ver en el ejemplo validar un número es tremendamente sencillo sin tener siquiera la necesidad de especificar una expresión regular para la validación de los mismos.

Ahora veremos un ejemplo de como usar estas validaciones dentro de nuestra aplicación.

try {
	String name = Tools.validateName(request.getParameter("name"));
} catch (IntrusionException ex) {
	request.setAttribute("resultados", "Detectada una intrusión");
	Tools.anadirMensaje(request, ex.getUserMessage());
} catch (ValidationException ex) {
	request.setAttribute("resultados", "Error en el formulario");
	Tools.anadirMensaje(request, ex.getUserMessage());
}

Escapar las entradas de usuario

ESAPI también nos permitirá escapar las entradas del usuario para introducirlas en la base de datos; pero la verdad es que usando PreparedStatements este paso no sería necesario, y en caso de querer hacerlo habría que hacerlo después de pasar la validación por expresiones regulares puesto que al escapar una cadena se van a incluir nuevos caracteres como la contrabarra “\”. Veamos a continuación un ejemplo sencillo para escapar las entradas preparado especialmente para MySQL (ESAPI proporciona métodos de escape para MySQL y para Oracle si no recuerdo mal).

protected String scapeUserEntries (String input){
	Encoder encod = ESAPI.encoder();
	return encod.encodeForSQL(new MySQLCodec(MySQLCodec.MYSQL_MODE), input);
}

Recomiendo que partiendo de los ejemplos y explicaciones que se han dejado aquí se eche un vistazo al javadoc de ESAPI puesto que contiene opciones bastante interesantes. Entre ellas tiene una forma de hacer validaciones seguidas poniendo los errores en una lista para hacer todo el conjunto de validaciones seguidas sin detenerse por el fallo de alguna de ellas.

Cross Site Scripting (XSS)

Ahora que hemos visto como evitar las inyecciones SQL veremos ahora las formas de evitar Cross Site Scripting, que a modo de resumen a lo que se comentó en el capítulo anterior se podría decir que el fin que se persigue con este tipo de ataques es introducir alguna información en la base de datos para que posteriormente sea mostrada a otros usuarios. La información que se suele introducir serán scripts que persiguen realizar alguna actividad ilegítima.

De la misma manera que en el apartado anterior se validaban las entradas de los usuarios para evitar la inyección SQL realizando esa validación es evidente que se puede evitar también el XSS.

Aunque el problema puede venir de un caso en el que no queramos usar una expresión regular para validar, por ejemplo un campo de comentarios para el usuario en el que se permite cualquier caracter. En este caso lo que habrá que hacer es buscar etiquetas html sospechosas como script, pero… ¿realmente vale con buscar este tipo de etiquetas? Pues la respuesta es que no, porque si se usa otra codificación ya no van a aparecer así las etiquetas. A continuación veremos una buena forma de validar las entradas para evitar el XSS.

El problema de las codificaciones

Lo primero veamos el problema de las codificaciones. En el siguiente ejemplo ambas líneas son equivalentes.


%3C%2Ftitle%3E%3Cscript%3Ealert%28%22%A1Este+Sitio+es+un+peligro%21%22%29%3C%2Fscript%3E

Ahora si vemos que no se puede proteger simplemente buscando etiquetas html ¿no?. Por lo tanto lo primero que habrá que hacer es pasar la cadena a una forma canónica.

Obtener la forma canónica de una cadena consiste en convertir toda la cadena a una codificación conocida y admitida para que de esta manera se eviten problemas en la posterior validación.

Usando AntiSamy para validar entradas en HTML

ESAPI también nos proporciona soluciones para todos los problemas comentados mediante un módulo llamado AntiSamy. Este se encarga de procesar código html y verificar si está permitido o por el contrario es un posible intento de intrusión, para ello usa un fichero xml de configuración en el que se especificarán con detalle las etiquetas html permitidas y no permitidas; también será posible especificar que tipo de propiedades de CSS se pueden usar.

El archivo xml de configuración de AntiSamy se puede colocar donde nosotros queramos, aunque, obviamente no sería una buena medida colocarlo en un directorio que sea accesible publicamente. En mi caso lo he colocado en el mismo sitio que los archivos de configuración de ESAPI, que si recordamos estaban en la carpeta setup que habíamos añadido al classpath.

En la página del proyecto de AntiSamy es posible encontrar varios archivos de configuración de ejemplo, de más a menos restrictivos. Lo mejor es partir de alguno de estos archivos y en caso de querer modificarlos hacerlo observando las directivas que ya contiene puesto que no es una tarea sencilla hacer un archivo de estos desde cero, por ello nos proporcionan varios ejemplos. También hay un ejemplo en su página de descargas muy interesante pensado para enviar datos al servidor que provienen de un TextArea con TinyMCE (Librería JQuery para dotar a un TextArea de un editor con WYSIWYG).

Ahora que hemos visto lo referente al fichero de configuración ya estamos en disposición de poner un ejemplo de un método que valida una entrada HTML. Este método que muestro a continuación valida una entrada que se le pasa como argumento y lanza una IntrusionException si la validación no ha pasado, dicha excepción la he lanzado yo para detectar los errores puesto que la librería no lanza excepciones ante una validación fallida, sino que anota los errores que han ocurrido y también tiene la posibilidad de eliminar aquello que no es válido según la configuración que hayamos hecho en el fichero xml.

Es importante ver también que como anoto en los comentarios antes de pasar la validación se obtiene la forma canónica del String usando un método que nos proporciona ESAPI. Y finalmente observar como se ha indicado donde esta el fichero xml de configuración, que se ha realizado usando el classpath y obteniendo su flujo de entrada.

public static void validateHTML(String input) {
    try {
		//No se admite una entrada vacía
        if (input.isEmpty() == true) {
            throw new IntrusionException("No se admite el campo vacío", "");
        }
		//Se obtiene el archivo de configuración a través del classpath
        Policy politica = Policy.getInstance(Tools.class.getResource("/antisamy-tinymce-1.4.4.xml"));
        AntiSamy validator = new AntiSamy();
		//Antes de analizar la cadena es convertida en su forma canónica
		//ESAPI.encoder().canonicalize(input)
        CleanResults cr = validator.scan(ESAPI.encoder().canonicalize(input), politica);

		//Si ha ocurrido un error se lanza una excepción indicando el error
        if (cr.getNumberOfErrors() != 0) {
            throw new IntrusionException("Ha introducido código HTML que no está permitido",
                    cr.getErrorMessages().get(0).toString());
        }
    } catch (PolicyException ex) {
        Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
    } catch (ScanException ex) {
        Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
    }
}

Anexo – Cerrar Conexiones, Statements y ResultSets. Varargs en java

En este apartado vamos a ver una buena manera de hacer esos métodos que decíamos para cerrar las conexiones y Statments. Aquí el problema viene de hacer un método que nos sirva para todos los métodos de la clase manejadora de la base de datos. No van a tener todos los métodos un Statement o un ResultSet, pueden tener varios de cada uno.

Se puede pensar en hacer métodos que reciban listas de Statements, pero estaríamos a lo mejor escribiendo líneas construyendo esas listas en cada método, líneas que se supone intentamos ahorrarnos. Pues bien java tiene algo llamado varargs para facilitarnos esta tarea, aunque internamente este construyendo listas el caso es que no tenemos que construirlas nosotros.

Lo único que hemos de hacer es colocar en la cabecera de los métodos de cierre unos puntos suspensivos detrás del tipo de dato. El argumento que vaya con varargs debe ser el último y debe haber solo uno (esto es debido a que sino java no tiene forma de saber los tipos de datos de los argumentos). Posteriormente dentro del método podemos recorrer los elementos con un bucle for-each, como si de un lista normal se tratara (que es de hecho lo que hace internamente como ya he dicho).

private void cerrarConexionYStatement(Connection conexion, Statement... statements) {
    try {
        conexion.close();
    } catch (SQLException ex) {
        logger.log(Level.SEVERE, "Error al cerrar una conexión a la base de datos", ex);
    } finally {
        for (Statement statement : statements) {
            if (statement != null) {
                try {
                    statement.close();
                } catch (SQLException ex) {
                    logger.log(Level.SEVERE, "Error al cerrar un statement", ex);
                }
            }
        }
    }
}

private void cerrarResultSet(ResultSet... results) {
    for (ResultSet rs : results) {
        if (rs != null) {
            try {
                rs.close();
            } catch (SQLException ex) {
                logger.log(Level.SEVERE, "Error al cerrar un resultset", ex);
            }
        }
    }
}

Estos métodos podrían admitir toda una serie de llamadas no dependiendo del número de Statement o ResultSet.

cerrarConexionYStatement(conexion, select);
cerrarConexionYStatement(conexion, deleteHistorialCarros, deleteProdCarro);

cerrarResultSet(rs);
cerrarResultSet(consultaDatosCarro, rs);

Como podemos suponer nos hemos ahorrado bastantes líneas en cada uno de los métodos, ahora como máximo habrá dos líneas en cada método para cerrar los recursos independientemente del número de recursos que haya.

Bueno, y hasta aquí esta guía de seguridad para aplicaciones web junto con el uso de ESAPI que como vemos llega a ser muy útil para las tareas de seguridad en nuestra aplicación.

También comentar que puede venir bien la lectura de los consejos que nos da OWASP para los dos problemas que hemos tratado en esta entrada (en inglés): Inyección SQL y Cross Site Scripting (XSS).

Comentar que todo lo que hemos aprendido en estos dos capítulos se refiera a la lógica de servidor como es evidente, esta lógica siempre debe existir, pero debo comentar que si se realizan validaciones en el cliente por ejemplo usando JavaScript se puede quitar un poco de carga al servidor, ya que ante una validación fallida esa petición no llegará al servidor.

Espero que os hayan sido útiles estas guías de seguridad, y como siempre digo a vuestra disposición quedo para cualquier duda problema o sugerencia.

Tutorial ANT: Uso con librerías externas y generadores JFlex y CUP

Juan — Mon, 28 Nov 2011 10:35:36 +0000

He dedicado tiempo ultimamente a aprender al menos de manera básica el uso ANT, que para los que no lo sepan es una herramienta para compilación de proyectos JAVA al estilo del make para C. Justo me proponen en la universidad que realice una presentación en clase sobre ello; no me ha podido venir más bien después de haber estado yo haciendo algunos ejemplos. Así que me dispuse a ordenar mis investigaciones para crear un ejemplo sencillo que aunara lo que considero más importante, y sobre ese ejemplo realizar una presentación que me ayudara a explicarlo en clase de la manera más ordenada posible.

Bueno, y ya que he hecho la presentación y el ejemplo pues me animo también a presentar aquí el tutorial

¿Qué es ANT?

Como ya he comentado ANT es una herramienta para compilación de proyectos JAVA, y como tal escrita en el mismo. Se podría decir que es una herramienta como make para programas en C solo que especialmente diseñada pensando en JAVA; nos proporciona los medios para la realización de las tareas que componen el proceso de compilación, documentación, distribución, etc de un proyecto JAVA.

Es muy útil para los casos en los que se trabaja con distintos entornos de desarrollo para disponer de una manera estándar y fácil de compilar el proyecto, y sobretodo en proyectos complejos con muchas librerías o en proyectos web en los que las tareas de compilación comprenden más pasos. Además la mayoría de los entornos de desarrollo disponen de opciones para la ejecución de scripts de ANT.

Por último comentar que actualmente no es ant la herramienta más usada para esto, sino que se está usando cada vez más una herramienta similar llamada Maven, la cual tiene algunas ventajas sobre el que ahora nos ocupa.

Instalación de ANT

La instalación de ANT es bien sencilla, básicamente consiste en situar los archivos de ant en las variables de entorno del sistema. Podemos conseguir los archivos de instalación en la web del proyecto. Pese a ser una obviedad comentaré que se necesita tener instalado el JDK (Java Developer Kit) puesto que ant está escrito en Java.

Mac OS

Yo no he tenido que hacer nada para instalarlo, o viene por defecto o se instaló con el Xcode de Mac OS.

Linux

Si suponemos que hemos situado los archivos ANT en /usr/local/ant

export ANT_HOME=/usr/local/ant
export JAVA_HOME=/usr/local/jdk-1.5.0.05
export PATH=${PATH}:${ANT_HOME}/bin

Windows

Si suponemos que hemos situado los archivos de ANT en C:\ant\

set ANT_HOME=c:\ant
set JAVA_HOME=c:\jdk-1.5.0.05
set PATH=%PATH%;%ANT_HOME%\bin

Si hemos instalado ant correctamente podremos teclear el comando para ver su versión en la consola y nos deberá reconocer el comando.

Para ejecutar ant sobre un fichero build.xml nos situaremos en el directorio donde este el fichero y teclearemos ant para ejecutar el objetivo por defecto o ant y un objetivo en concreto para ejecutar ese objetivo concreto (se ejecutarán también sus dependencias obviamente)

#Obtener la versión instalada de ant
$ant -version

#Ejecutar un script de ant con el objetivo por defecto
$ant

#Ejecutar un script de ant con el objetivo que elijamos
$ant objetivo

Algunas definiciones

Vamos a ver en este apartado algunos conceptos que hemos de conocer para trabajar con ANT.

Mientras que en el famoso make de C teníamos un fichero llamado makefile, en este caso tendremos un fichero xml llamado build.xml en el que estarán escritos los pasos que se han de seguir para la compilación de nuestro proyecto. Pasemos ahora a definir los elementos de dicho fichero (o etiquetas puesto que es un fichero XML).

project: Es el elemento raíz del fichero XML y como tal solo puede haber uno en el fichero. Es el propio proyecto con el que estamos trabajando
target: Elemento que agrupa un conjunto de tareas que se desean realizar en un momento determinado. Como veremos puede haber unos objetivos dependientes de otros
task: Es el código ejecutable que será aplicado a la aplicación en algún momento, puede contener distintas propiedades.
property: Parámetros en forma de par clave-valor (los nombres serán case-sensitive) para personalizar el proceso de construcción o simplemente como accesos directos a un dato que se use de manera repetitiva en el fichero xml.

Continuemos ahora viendo una estructura de directorios para un proyecto Java.
En primer lugar tenemos el directorio classes en donde se almacenarán las clases Java compiladas.

Dentro del directorio dist se encontrará la aplicación empaquetada en forma de jar autoejecutable, también se podía incluir aquí la documentación para su distribución aunque he optado por ponerla en la raíz del proyecto.

En el directorio doc estará la documentación del proyecto en formato javadoc.

En el interior del directorio lib estarán almacenadas las bibliotecas externas que hayamos usado en nuestro proyecto.

Por último el directorio src en el que estará el código fuente de la aplicación organizado en los paquetes que hayamos decidido nosotros mismos.

Nuestro primer build.xml

Vamos a ver aquí nuestro primer ejemplo y sobre él explicaremos las partes básicas a parte de las etiquetas ya explicadas.

Lo primero que nos encontramos es que la raiz del fichero tiene dos atributos que no hemos explicado anteriormente. El primero de ellos es default, este especifica cual es el objetivo que se ejecutará por defecto al ejecutar este script de ant salvo que se especifique uno concreto. El atributo basedir indica donde están situados los directorios del proyecto. En este caso como tendremos el fichero buid.xml al mismo nivel que los directorios del proyecto hemos puesto un punto.

Lo siguiente que nos encontraremos serán las propiedades que como dije son pares clave valor. En este caso yo las he usado para tener un acceso más rápido a los distintos directorios y menos problemas si alguno de ellos fuera cambiado. Accederemos a ellas posteriormente así ${propiedad}

Finalmente nos encontramos con un objetivo sencillo que realiza la compilación con la tarea javac, tiene como atributos srcdir que indica donde está el código fuente a compilar y destdir indica en que directorio se han de dejar las clases compiladas.

Los objetivos pueden tener dependencias, las cuales se indican con el atributo depends. Las dependencias entre objetivos indican que un objetivo que depende de otro no será ejecutado sin que se haya ejecutado previamente ese otro del que depende. Veamos un ejemplo sencillo

Empaquetado del proyecto

En este apartado veremos como crear un objetivo que se encargue de empaquetar las clases compiladas en un único jar autoejecutable.

Un archivo jar es como un archivo zip, incluso con la misma compresión; y en su interior contiene las clases java organizadas en paquetes y una carpeta más llamada META-INF, esa carpeta es la usada para meter en su interior meta-información sobre el archivo jar.

Dentro de la carpeta nombrada se suele encontrar un fichero llamado manifest.mf, el cual tiene en su interior un conjunto de pares clave valor que pueden ser necesarios. En nuestro ejemplo lo que indicaremos en el fichero será cual es la clase main (Main-Class) de nuestro proyecto para que se sepa por donde tiene que empezar la ejecución. Sin esto no podríamos ejecutar el archivo jar, al menos con el típico doble click, habría que hacerlo pasando por la consola y llamando directamente a la clase Main.

Como hemos visto, la tarea jar contiene dos atributos, el primero de ellos llamado destfile que indicará la ruta donde queremos el fichero jar generado, el atributo basedir indica donde se encuentran las clases compiladas a incluir y finalmente el atributo includes que me indicará que tipo de ficheros se incluyen dentro del fichero jar creado.

Como se puede ver, un nivel por debajo de la tarea jar nos encontramos con la etiqueta manifest, la cual, como podemos suponer, sirve para incluir conjuntos de pares clave valor dentro del fichero que comenté anteriormente. Como se observa se indica la ruta a la clase main tal y como hemos comentado.

Generación de documentación

En este apartado veremos como crear un objetivo que cree documentación javadoc sobre nuestro proyecto. Vamos a poner aquí un pequeño ejemplo y lo explicaremos posteriormente.

Como vemos la tarea que se encarga de generar la documentación javadoc del proyecto tiene bastantes atributos, los primeros de ellos son los más importantes de todos. El primero de ellos, packagenames, indica los paquetes sobre los que se desea generar la documentación, esta vez hemos puesto asterisco para generar la documentación de todos ellos, sourcepath es el directorio donde se encuentran los archivos fuente del proyecto, destdir indica el directorio donde se van a guardar los archivos generados en el proceso de documentación (el resultado final).

Los demás atributos que observamos son de menos importancia que los anteriores ya que se refieren más a la personalización de esa documentación a generar, por ejemplo tomar en cuenta etiquetas @author o @version, el título y el pie de página del documento, etc…

Limpieza e Inicialización

Entre las muchas tareas predefinidas con las que cuenta ant podemos encontrar tareas para crear y borrar carpetas (y archivos).

Puede ser que queramos borrar las clases compiladas antes de una nueva compilación para que no haya problemas, y obviamente también habrá que crear las carpetas después de borrarlas.

Veamos aquí dos ejemplos de objetivos de ejemplo para crear y borrar carpetas. En este ejemplo haremos que se borre el paquete jar autoejecutable, las clases compiladas y la documentación generada; parece lo más lógico hacerlo así para evitar problemas si hay cambios grandes en la estructura de clases y paquetes.

Como podemos ver la tarea delete tiene como función borrar directorios y con los atributos se indica que es lo que se quiere borrar. Y, con la tarea mkdir se hace lo contrario, crear directorios.

Como podeis ver el objetivo init depende del objetivo limpiar. Lo que quiere decir que llamar al objetivo init impicará borrar todo lo anterior y dejar las carpetas listas para la compilación, empaquetado y generación de documentación.

Utilización con librerías externas

En este apartado veremos como trabajar con librerías externas y veremos como hacer las tareas que ya hemos realizado pero usando librerías externas.

Es posible hacer referencia a una carpeta con librerías de varias formas, pero si se quiere usar esa referencia en varios lugares del fichero build.xml la mejor forma es hacer uso del elemento path, dentro del cual se selecciona la carpeta con las librerías, pudiéndose también hacer uso de filtros para seleccionar solo determinados ficheros.

Posteriormente habrá que usar ese elemento para incluirlo en el classpath durante la compilación y la generación de la documentación

Y en lo que respecta a la tarea del empaquetado de las clases compiladas hay que tener en cuenta dos cosas, en primer lugar para incluir un fichero jar de librerías en el paquete autoejecutable jar generado lo que se realiza es una descompresión del jar de las librerías para incluirlo en el jar final. Como resultado de este proceso obtendríamos la carpeta META-INF del paquete de las librerías, que de no ser excluido sobreescribiría la carpeta META-INF junto con el manifiesto creado, por lo que se perdería la meta-información que añadíamos a nuestro fichero jar final, y si esta información se perdiese la máquina virtual de JAVA no sabría cual es la clase Main para ejecutar el paquete.

Por lo tanto, para realizar estas tareas usaremos el elemento zipfileset indicando el fichero comprimido a incluir junto con un filtro para excluir la carpeta META-INF como ya hemos dicho.

Ejecución

En este apartado veremos como ejecutar el proyecto tanto desde una clase java como desde el proyecto empaquetado en un jar.

Ejecución desde clase Java

La tarea que nos ayudará a la ejecución es java, y usaremos el atributo classname para indicar la clase a ejecutar, para que pueda encontrar dicha clase tendremos que definir el atributo classpath con la ruta donde esta el paquete y la clase que hemos dicho que tenga que ejecutar.

Para poner los argumentos tendremos que usar arg y el argumento se pondrá en el atributo value. También hay que tener en cuenta que habrá que indicar la ruta de las librerías referenciando al elemento path que creamos en el apartado anterior.

Ejecución desde un archivo jar

Para este caso seguiremos usando la tarea java pero en este caso con el atributo jar en el que indicaremos la ubicación del archivo jar a ejecutar. Recordemos que para que la máquina virtual de java (VM) sepa que clase tiene que ejecutar tendremos que haber definido bien las propiedades en el manifiesto como ya explicamos anteriormente.

Es obligatorio el uso del atributo fork puesto que para ejecutar este jar la VM creará una nueva instancia. Como opción podemos usar el atributo maxmemory para indicar la máxima memoria que se reservará para la nueva instancia de la VM.

El resto será igual que en el caso anterior indicando los argumentos y añadiendo al classpath el elemento path que se definió anteriormente.

Usando ANT con JFlex y CUP

Como consecuencia de haber preparado la presentación para una asignatura sobre procesamiento de lenguajes vamos a tener un apartado extra en este tutorial. Este añadido tratará sobre como automatizar la utilización de Jflex (Generador de analizadores léxicos) y CUP (Generador de analizadores sintácticos).

Pues bien, lo primero que tendremos que hacer es decargar las librerías de JFlex y CUP para situar sendos Jar en la carpeta de librerías.

Conviene saber que ambos generadores contienen en el interior de sus librerías una tarea de ant, por lo que nuestro trabajo consistirá únicamente en usar dichas tareas.

Como vemos usamos el elemento taskdef y como atributos señalamos la carpeta de librerías que ya habíamos definido anteriormente en el apartado donde veíamos como usar librerías externas, posteriormente indicamos la clase en la que se encuentra esa tarea de ant y finalmente se indica el nombre bajo el que se usará esa tarea en el documento build.xml.

Mostramos ahora un objetivo encargado de la generación de los analizadores y posteriormente pasaremos a explicar cada uno de los atributos usados.

JFlex

En lo que se refiere a la tarea de jflex contamos con el atributo file en el cual se indica el fichero flex del que se partirá para la generación del analizador léxico, y finalmente destdir que indica el directorio en el que se generará el fichero java generado organizado en paquetes según se indique en el fichero flex.

CUP

En la tarea de CUP tenemos el atributo srcfile, equivalente al file de Jflex y destdir también equivalente al atributo del mismo nombre en Jflex. También se pueden usar otros atributos como interface para crear una interfaz java en vez de una clase. CUP también producirá su salida organizada en el paquete que se haya especificado en el fichero cup.

Recursos

Como parte de este tutorial dejaré aquí la presentación a modo de resumen y un proyecto de ANT como ejemplo.

En el proyecto de ejemplo se ha creado un objetivo de ant para explicar su uso, por lo que si queremos saber las opciones que tiene este fichero de configuración habrá que usar la siguiente orden en la consola situados en la carpeta del proyecto.

$ant usage

Hasta aquí este tutorial sobre ANT. Espero que os haya sido de utilidad, como siempre digo quedo abierto a todo tipo de sugerencias o adiciones; tenéis los comentarios a vuestra disposición.

Java EE: Seguridad en aplicaciones web (I)

Juan — Mon, 31 Oct 2011 23:03:37 +0000

Hace ya unos meses, publiqué una presentación que hice en la universidad sobre seguridad en las aplicaciones web, en concreto con Java EE. Ahora lo que me dispongo a hacer es repasar las partes más importantes de aquella charla en incluso aportar alguna cosa más sobre el tema después de haber estado trabajando con ello en la tienda online. Al ser un tema bastante amplio será distribuido entre varios artículos.

En esta serie de artículos aprenderemos a usar las herramientas que nos proporcionan las librerías de la empresa OWASP. También aprovecharemos para fijarnos en sus consejos ya que se dedican a estudiar entre otras cosas los problemas que yo voy a nombrar aquí.

Introducción – Principios de seguridad

Antes de nada vamos a dar una guía de buenas prácticas que es interesante conocer antes de empezar a construir aplicaciones para conseguir un trabajo lo más bueno posible.

No dar nunca nada por hecho ni en cuestiones de seguridad ni en cuestiones del flujo normal de la aplicación. Todo el riesgo que se corra debe ser por parte del usuario (no hay nada que hacer contra eso). Me explico, no supongamos que si le pido el nombre al usuario no me va a poner un número de teléfono. No se si sería una forma acertada de decirlo pero hay que pensar con pesimismo, en los peores casos, y por remotos que sean pueden ocurrir.

Siempre que usemos servicios externos estamos asumiendo riesgos añadidos. Podemos haber hecho una página web muy segura y muy bien construida, pero si incrustamos contenido externo nadie nos asegura que el contenido externo sea vulnerable a algún tipo de ataque.

La oscuridad no es seguridad. No poner un botón acceso a la administración no impide que se pueda acceder a ella. Ocultar nuestro código no debe ser parte de nuestra seguridad.

Principio del mínimo privilegio: El usuario del sistema debe tener únicamente los privilegios que necesita para llevar a cabo su actividad.

Fallar de manera segura: Hay que tratar de manera muy cuidadosa los fallos en la aplicación. Por poner un ejemplo, si se produce un fallo en la aplicación mientras se realizan tareas administrativas no debe seguir iniciada la sesión como administrador. Otro ejemplo, no debe mostrar en un fallo información técnica sobre el mismo al usuario del sistema. Si el usuario sabe datos acerca de nuestro sistema podría tener más fácil la búsqueda de vulnerabilidades.

Los riesgos

Ahora que hemos dado unos pequeños consejos sobre seguridad a la hora de la construcción de aplicaciones ya podemos pasar a explicar los riesgos que hay en las aplicaciones web. No vamos a ponernos a programar nada sin saber los riesgos existentes y el porque de las medidas que se toman para combatirlos.

Voy a nombrar aquí los riesgos que considero más importantes.

Inyección SQL: Consiste en intentar “engañar” al sistema para que realice peticiones contra la base de datos que no son las que han sido programadas y que podrían comprometer gravemente la base de datos o incluso mostrar al atacante toda la información de la misma.

Cross Site Scripting: El atacante intentará enviar información a nuestro servidor por medio de nuestros formularios u otros medios con la intención de que dicha información sea almacenada en nuestra base de datos y posteriormente sea mostrada a los demás usuarios del sistema. Un ejemplo sencillo: Un código JavaScript que borre el contenido de la página, si eso es mostrado a los demás usuarios de la aplicación verán siempre una página en blanco. Esto es un ejemplo sencillo, pero imaginarios que lo que se consigue introducir es un código que tome el control de los navegadores de los usuarios de la aplicación web.

Robo de sesión: Como sabemos HTTP es un protocolo sin estados, lo que significa que las credenciales o información de sesión deberá ir en cada petición; debido a esto dichos datos resultan muy expuestos. Un robo de estos datos podría tener como resultado que alguien se estuviera haciendo pasar por nosotros y realizando acciones con unos privilegios que nos pertenecen. Y tampoco hemos de olvidar que se pude robar la sesión intentando obtener nuestros credenciales de alguna manera (averiguar nuestra contraseña).

Acceso a URLs restringidas: Consiste en la observación de una URL e intentar cambiarla para intentar acceder a otras zonas. Estas es una de las razones por las que la seguridad a través de la ocultación no es efectiva.

Solucionando los problemas de seguridad

Ahora que ya hemos identificado y visto en que consisten los problemas que nos podemos encontrar en las aplicaciones web, o al menos lo más importantes y peligrosos vamos a ir uno por uno explicando como hemos de solucionarlos. Iremos primero a los dos últimos que son los más sencillos y en posteriores entradas explicaremos la solución a los dos primeros que son los más importantes de los cuatro y quiero dedicarles una entrada completa.

Robo de sesión

Ya hemos visto el riesgo que tiene el robo de una sesión. Podríamos decir de manera resumida que el peligro está en la exposición de los datos de sesión. En la ilustración de la presentación de seguridad que hice podemos ver una posible situación de robo de sesión.

Para solucionar este problema de seguridad hay que atenerse a varios aspectos de la seguridad: la autentificación y la sesión; para cada uno de ellos veremos varios aspectos importantes a cubrir para solucionar problemas con el robo de sesión.

La Autentificación

El más importante de todos. Usar SSL sobre HTTP (HTTPS) para transferir los datos y asegurarse de que el cifrado cubre los credenciales y el ID de sesión en todas las comunicaciones. De esta manera los datos de sesión de los que hablábamos siguen estando expuestos pero esta vez se encuentran cifrados, por lo que no se pueden usar. Alguien podría pensar: “¿Y si se obtiene la sesión y se rompe la encriptación?”, la respuesta es sencilla, y es que con los medios actuales para cuando hayas conseguido romper la encriptación esa sesión habrá dejado de existir.

Usar un sistema de autentificación simple, centralizado y estandarizado. Es mejor que usemos métodos de autentificación que nos proporcione el propio servidor de aplicaciones en vez de soluciones implementadas por nosotros, debido a que lo que implementa el servidor de aplicaciones es usado en muchos lugares y ha sido suficientemente probado. Por ejemplo los filtros de Java EE (que veremos posteriormente) o los métodos de autentificación que proporciona Java EE (no los he usado).

Posibilitar el bloqueo de autentificación después de un número determinado de intentos fallidos. Esto podría evitar ataques de fuerza bruta intentando averiguar la contraseña del usuario.

Implementar métodos seguros de recuperación de contraseñas: Es común que se intenten usar estos métodos para intentar ganar acceso a una cuenta del usuario, podemos ver una serie de consejos para implementar estos métodos. Pedir al usuario al menos tres datos o más, obligar a que responda preguntas de seguridad. La contraseña que recuperada deberá generarse de manera aleatoria (con una longitud de al menos 8 caracteres) y enviada al usuario por un canal diferente (E-mail); de esta forma si el atacante consiguió sortear los primeros pasos es difícil que logre sortear el canal usado para transmitir.

La Sesión

Usar los métodos de sesión que nos proporciona el servidor de aplicaciones que estemos usando, y digo esto por las mismas razones que aconsejé usar los métodos de autentificación que proporciona el servidor de aplicaciones. En este caso no estamos refiriendo a la sesión y a las cookies.

Asegurar que la operación de cierre de sesión realmente destruye dicha sesión. También fijar el periodo de expiración de la sesión (periodo de tiempo en el que no se realice ninguna acción bajo dicha sesión); por ejemplo para aplicaciones críticas de 2 a 5 minutos, mientras que para otras aplicaciones más comunes se podría usar de 15 a 30 minutos.

En el descriptor de despliegue podemos fijar la caducidad de la sesión en minutos.

Ahora que hemos visto las formas de evitar el robo de sesión; o al menos de manera teórica, ahora vamos a ver como se hacen esta serie de cosas en la práctica.

Hemos hablado de usar métodos proporcionados por el servidor de aplicaciones para realizar la autenticación usando filtros y la sesión. Vamos a ver en concreto como podría hacerse. En primer lugar habrá que comprobar si los datos de usuario son correctos y posteriormente se podría hacer algo como añadir algún parámetro a la sesión indicando que esta autenticada. Voy a simplificar mucho un código para que nos centremos en lo fundamental.

if (password.equals(user.getPass()) == true) {
	//Se añade a la sesión un boolean indicando que está autentificado
	request.getSession().setAttribute("auth", true);

	//Se añade a la sesión el identificador del usuario
	request.getSession().setAttribute("usuario", user.getMail());
}

Respecto a bloquear el inicio de sesión después de un número determinado de intentos fallidos podría ser tan fácil como añadir a la sesión el número de intentos fallidos y en el caso de que superen un determinado número no ejecutar ningún mecanismo de autenticación ni mostrar el formulario de login, únicamente habría que lanzar un timer para desbloquear el inicio de sesión pasado un tiempo.

protected void starTimer(final HttpSession sesion) {
	//Tarea que se lanzará cuando el Timer la ejecute
    TimerTask timerTask = new TimerTask() {

        @Override
        public void run() {
            sesion.invalidate();
        }
    };

    Timer timer = new Timer ();
	//El tiempo esta en milisegundos y se lanza la tarea que definimos anteriormente
    timer.schedule(timerTask, 600000);
}

Luego, para comprobar este parámetro (el que se ha añadido a la sesión para comprobar si se ha autentificado o no) sería factible usar filtros para todas las URLs para las que se necesite permiso y en ellos comprobar si existe el parámetro añadido en la sesión o no.

Lo primero de todo en el descriptor de despliegue (web.xml) hemos de configurar el filtro. Definiremos el filtro para un patrón de URL, en este caso todas las estén dentro del directorio /admin. Como sabemos los filtros actúan ante las peticiones de cliente para los patrones de URL para los que estén definidos. ¿Es esto del todo cierto? Pues no, en Java EE 6 esto ha cambiado un poco y podemos especificar que un filtro se ejecute sin necesidad de que el cliente haga una petición, simplemente con que el servidor haga una redirección porque así lo especifique el código (repito, sin que el cliente tenga nada que ver y sin que sepa nada de esa redirección). Podemos hacer esto mediante las sentencias que he dejado resaltadas.



	AdminFilter
	control.admin.AdminFilter



	AdminFilter
	/admin/*
	REQUEST
	FORWARD
	INCLUDE
	ERROR

Ahora veremos la clase que implementa el filtro y veremos que es a la misma clase a la que se hace referencia en el descriptor de despliegue. En ella simplemente se comprueba la existencia de los parámetros que se añadieron a la sesión en el proceso de autenticación. Los nombres de las variables son claros por lo que no he hecho comentarios, me parece que se ve claro el objetivo del código

Unicamente comentar que un Servlet no es exclusivo de una aplicación web, un ServletHttp es una clase de Servlet especial por así decirlo, de ahí que con el ServletRequest que nos da el filtro no podamos obtener la sesión y por eso necesitamos la primera línea del método doFilter en la que se hace un casting.

package control.admin;

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;

/**
 * @author Juan Díez-Yanguas Barber
 */
public class AdminFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
		//Obtenemos un HttpServletRequest con un casting
        HttpServletRequest requestMod = ((HttpServletRequest) request);
        if (isPermited(requestMod) == false){
            requestMod.getSession().setAttribute("requestedPage", requestMod.getRequestURL().toString());
            RequestDispatcher noPermited = request.getRequestDispatcher("/WEB-INF/paginasError/restricted.jsp");
            noPermited.forward(request, response);
        }else{
			//Continua la secuencia de ejecución normal
            chain.doFilter(request, response);
        }
    }

    private boolean isPermited(HttpServletRequest request) {
        if (request.getSession().getAttribute("auth") == false || request.getSession().getAttribute("usuario") == null) {
            return false;
        } else{
            return true;
        }
    }

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }

    @Override
    public void destroy() {
    }
}

Ahora veremos como cerrar la sesión de la manera más correcta. Lo más correcto sería destruir la sesión, de esta manera nuestra sesión dejará de existir a todos los efectos. Para ello usaremos la siguiente sentencia, cuya función es destruir la sesión. La podríamos usar por ejemplo en un Servlet encargado del cierre de sesión.

request.getSession().invalidate();

Respecto al tema de las contraseñas voy a dedicar al final de esta entrada un apartado donde explicaré como trabajar correctamente con ellas.

Acceso a URLs restringidas

Como ya hemos visto en el apartado teórico sobre este problema la seguridad a través de la ocultación no sirve de nada. Si por ejemplo para la parte pública se usara un patrón de URL /public el atacante podría pensar que la parte privada pudiera ser /admin o cosas parecidas, con no dar a conocer el detalle de ese directorio no es suficiente, hay que protegerlo.

Como a estas alturas supondremos no hay que hacer nada especial si se ha realizado lo anterior, es decir, si hemos realizado una autenticación y un control de sesión correctos. Con el uso de los filtros podríamos solucionar este problema perfectamente.

Se que es un problema que a la vista parece bastante evidente y con una solución sencilla; pero mientras siga apareciendo como uno de los problemas más graves de seguridad será porque no está tan bien solucionado aunque sea evidente el problema y la solución.

Trabajando correctamente con contraseñas

Las contraseñas son un dato delicado, la palabra secreta que usa el usuario para acceder a su cuenta en el sitio web, algo suyo y personal. Por este motivo únicamente el usuario debería conocer su contraseña. Ahora bien, si solo conoce él la contraseña… ¿Cómo la comprobamos cuando inicie sesión? Vamos a ver que si que es posible hacerlo sin conocer la contraseña; lo haremos usando una huella digital MD5 o SHA1 (he puesto los enlaces en inglés, me parecían más completos).

En definitiva estos dos son los algoritmos más usados para la generación de huellas digitales, consistentes en crear una suma siempre de igual longitud independientemente del tamaño del mensaje y con la particularidad de que no se puede volver al mensaje original a partir del mensaje encriptado; pero un mismo mensaje siempre genera el mismo código.

//Método para generar la huella MD5
public static String generateMD5Signature(String input) {
    try {
		//Cambiando MD5 por SHA-1 podríamos obtener la huella usando este otro algoritmo
        MessageDigest md = MessageDigest.getInstance("MD5");
        byte[] huella = md.digest(input.getBytes());
        return transformaAHexadecimal(huella);
    } catch (NoSuchAlgorithmException ex) {
        Logger.getLogger(Tools.class.getName()).log(Level.SEVERE,
                "No se ha encontrado el algoritmo MD5", ex);
        return "-1";
    }
}

//Método para transformar el array de bytes en una cadena hexadecimal
private static String transformaAHexadecimal(byte buf[]) {
    StringBuilder strbuf = new StringBuilder(buf.length * 2);
    for (int i = 0; i < buf.length; i++) {
        if (((int) buf[i] & 0xff) < 0x10) {
            strbuf.append("0");
        }
        strbuf.append(Long.toString((int) buf[i] & 0xff, 16));
    }
    return strbuf.toString();
}

A sabiendas de lo anterior podríamos darnos cuenta de que si en vez de guardar la contraseña de los usuarios guardamos la huella digital de la misma podremos verificar su identidad cuando él inicie sesión, y no tendremos su contraseña guardada ni modo alguno de obtenerla. Lo que habrá que hacer es obtener la huella de su contraseña cuando el usuario la introduzca y la compararemos con la huella que nosotros teníamos guardada.

Así estaremos protegiendo al usuario; si nuestra base de datos se viese comprometida y llegamos a tener guardadas las contraseñas todos nuestros usuarios estarían expuestos, mientras que de esta manera que explico esto no ocurriría.

¿Es este método infalible? Pues no, existen tablas de huellas de palabras clave que se suelen usar, ya se sabe que no solemos ser bastante ocurrentes poniendo las palabras clave (solemos usar 1234, password, etc…), así que si disponen de una tabla de este tipo podrían obtener las contraseñas a partir de las huellas de nuestra base de datos comprometida (si bien no obtendrán todas, alguna seguro que sí).

Pues bien, aún con estos problemas nos quedan armas a usar. Si en vez de guardar las huellas de las contraseñas, guardamos las huellas de las contraseñas sumado con algo más. Si obtienen el mensaje que formó esa huella con una tabla de esas obtendrían la contraseña más eso que añadimos nosotros, luego no obtienen la contraseña. Y esto podría admitir muchas variaciones, como poner caracteres por enmedio de la contraseña, al final, al principio, lo que se añada a la contraseña podría ser tan complejo como desearamos. Pero sin olvidarse que al comprobar la contraseña habrá que hacer el mismo proceso.

Vamos a ver un ejemplo sencillo, mostraremos como se introduce la contraseña cuando el usuario se registra y como se comprueba cuando inicia sesión. En este caso vamos a añadir al final de la contraseña el nombre de usuario del sistema (Podría haber problemas si se cambiara el nombre de usuario en la máquina, pero no me voy a centrar en eso ahora, esto pretende ser solo un ejemplo ilustrativo).

String pass = request.getParameter("pass");
pass = Tools.generateMD5Signature(pass + System.getProperty("user.name"));

Veamos ahora el proceso de comprobación (user será el usuario que tenemos guardado ya en la base de datos y del cual tenemos su huella de la contraseña más el añadido).

String pass = request.getParameter("pass");
if (Tools.generateMD5Signature(password + System.getProperty("user.name")).equals(user.getPass()) == true) {
	//Contraseña correcta
} else {
	//Contraseña incorrecta
}

Ahora la cuestión viene cuando hacemos un método para recuperar la contraseña, no la podemos recuperar de forma alguna, no la hemos guardado. Por lo tanto, lo que habrá que hacer es generar una nueva y asignarla al usuario y mandarle la nueva contraseña por correo.

//Como argumento la longitud de la contraseña
String newPass = RandomStringUtils.randomAlphanumeric(19);
String newPassHash = Tools.generateMD5Signature(newPass + System.getProperty("user.name"));
//Asignar newPassHash al usuario

Hasta aquí llegamos con este artículo, como ya he comentado, trataré los otros problemas de seguridad de artículos posteriores. Espero que os haya sido de utilidad y os ayude a hacer aplicaciones web más seguras. También podeis encontrar más información en la web de OWASP sobre la autentificación y sobre más cosas que hemos estado tratando.

Digo lo mismo de siempre, estoy a vuestra disposición para dudas, comentarios o lo que sea; por supuesto también podeis aportar alguna otra cosa que consideréis interesante.

Java EE 6: Subida de imágenes al servidor (Servlet 3.0)

Juan — Wed, 12 Oct 2011 09:12:12 +0000

Vamos a ir poco a poco centrándonos en algunas partes concretas del proyecto que presente de la tienda online y así veremos en detalle determinadas partes. Hoy nos vamos a centrar en ofrecer la posibilidad de que el cliente de nuestra web pueda subir imágenes a nuestro servidor web de una manera muy sencilla

Antes de la especificación 3.0 de los Servlets esta tarea se tenía que hacer usando las librerías de Apache Commons y se convertía en una tarea más larga y menos clara; desde la nueva especificación no es necesario usar ninguna librería externa dado que nos da esta posibilidad de serie y de una manera muy sencilla. Pues bien, comencemos.

El formulario

Lo primero que hay que hacer es una pequeña modificación en el formulario donde se quiera subir la imagen, puesto que ahora los datos no se van a enviar en modo texto sino como un flujo binario, y teniendo en cuenta esto último el verbo HTTP usado será POST y nunca GET; de manera que la cabecera de nuestro formulario tendra una forma como la que os muestro.

Una vez que ya tenemos la estructura del formulario HTML, ya podemos añadir los campos que queramos al formulario al igual que lo hacemos normalmente, sabiendo que el campo para seleccionar la imagen sera de tipo file. Una vez hecho nos quedaría algo como lo que sigue.


            Nombre 

            


            Escoja una foto de producto (Opcional)

            


            Detalles 

            Puede usar etiquetas html (si usa etiquetas invalidas sera bloqueado)

Procesando el formulario

Una vez que ya tenemos el formulario HTML preparado ya estaríamos en condiciones de pasar a la parte de servidor para procesar este formulario que hemos creado; es decir, crear el Servlet encargado de procesar este formulario; que veremos que se procesa de una forma algo distinta a como estamos acostumbrados; principalmente debido a que ahora no hemos recibido texto sino un flujo de datos y de ahí tendremos que obtener el texto normal y la fotografía. En el formulario he puesto tres tipos de campos para que veamos como procesar cada uno de ellos (texto, archivo, textarea).

En primer lugar el Servlet encargado de procesar el formulario deberá llevar la anotación @MultipartConfig. Y ahora puede haber varias preguntas clave.

¿Cómo se si se ha enviado la imagen o no? (el usuario pudo no poner la imagen). Sencillo, si el Part (nombre que se le da a un campo en un formulario de este tipo) ocupa cero bits.
¿Cómo se si el archivo que se ha seleccionado es una imagen? Hay un método para saber el tipo de archivo subido. Si contiene la cadena image sabremos que es una imagen (image/jpeg, etc…)
¿Cómo guardamos la imagen en disco? Tendremos que obtener el InputStream del Part.
¿Cómo obtenemos los campos que son de tipo texto, ahora no recibo texto? Ahora veremos que hay una manera sencilla de hacerlo. Os enseñaré los métodos de la clase estática Tools.

Ahora os muestro el código del Servlet completo, he puesto algunos comentarios en el mismo. Está basado en uno de los Servlets de tienda online, he quitado bastante código para mostrar prácticamente solo lo referente al tema que nos concierne ahora en concreto, obviamente entendiendo lo fundamental podemos modificarlo para que cumpla con la función que cada uno desee. En el código veremos que se resaltan las líneas fundamentales que responden a cada una de las preguntas que he planteado en el párrafo anterior. Por supuesto el Servlet estará dado de alta en el descriptor de despliegue y atendiendo peticiones en la ruta a la que se envía el formulario HTML.

import control.Tools;
import java.io.IOException;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.annotation.MultipartConfig;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * @author Juan Díez-Yanguas Barber
 */

//Anotación necesaria para procesar formulario
@MultipartConfig
public class AddServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
				response.sendError(404);
    }

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        if (validateForm(request)) {
				//Extraemos el texto del formulario
                String nombre = Tools.getcontentPartText(request.getPart("name"));
                String detalles = Tools.getContentTextArea(request.getPart("detail"));                               

				//Comprobamos si el formulario contiene o no la imagen (usamos el tamaño para comprobar si existe el campo o no)
                if (request.getPart("foto").getSize() > 0) {
					//Nos aseguramos que el archivo es una imagen y que no excece de unos 8mb
                    if (request.getPart("foto").getContentType().contains("image") == false ||
                            request.getPart("foto").getSize() > 8388608) {
						// TIPO DE ARCHIVO NO VALIDO
                        request.setAttribute("resultados", "Archivo no válido");
                        Tools.anadirMensaje(request, "Solo se admiten archivos de tipo imagen");
                        Tools.anadirMensaje(request, "El tamaño máximo de archivo son 8 Mb");
                        request.getRequestDispatcher("/admin/add.jsp").forward(request, response);
                        return;
                    }else{
						//Obtenemos la ruta absoluta del sistema donde queremos guardar la imagen
                        String fileName = this.getServletContext().getRealPath("/images/products/imagen");
						//Guardamos la imagen en disco con la ruta que hemos obtenido en el paso anterior
                        boolean ok = Tools.guardarImagenDeProdructoEnElSistemaDeFicheros(request.getPart("foto").getInputStream(), fileName);
                        if (ok == false){
                            request.setAttribute("resultados", "Fallo al guardar archivo");
                            Tools.anadirMensaje(request, "Ocurrio un error guardando la imagen");
                            request.getRequestDispatcher("/admin/add.jsp").forward(request, response);
                            return;
                        }
                    }
                }
				//TODO CORRECTO SE REDIRIGE A UNA PAGINA DE VISUALIZACIÓN
				Producto prod = new Producto(nombre, detalles);
				request.getSession().setAttribute("productoEnCursoAdd", prod);
				request.setAttribute("operation", "add");
                RequestDispatcher previsualizacion = request.getRequestDispatcher("/WEB-INF/admin/view.jsp");
                previsualizacion.forward(request, response);
        } else {
            request.setAttribute("resultados", "Formulario no válido");
            Tools.anadirMensaje(request, "El formulario recibido no tiene los campos esperados");
            request.getRequestDispatcher("/admin/addproduct.jsp").forward(request, response);
        }
    }

	//Método para validar que el formulario contiene los parámetros correctos
    private boolean validateForm(HttpServletRequest request) throws IOException, ServletException {
        if (request.getParts().size() >= 4 && request.getPart("name") != null &&
                request.getPart("detail") != null && request.getPart("send") != null) {
            return true;
        }
        return false;
    }

    @Override
    public String getServletInfo (){
        return "Servlet para añadir productos al catálogo";
    }
}

Resumiendo, lo primero que hace el servlet es comprobar que se reciben los parámetros correctos y no menos, si la validación ha sido correcta se obtienen los campos de texto como veremos ahora. Posteriormente comprobamos si hay archivo o no, y en caso de que lo haya comprobamos que es una imagen y que el tamaño no exceda de 8 Mb, posteriormente se guarda en disco el archivo. Si quereis obtener más información sobre el archivo os animo a que investigueis los métodos del objeto Part. Es enviado un error 404 para una petición GET que llegue a este servlet debido a que no tendría porque accederse por dicho verbo HTTP (no hay ninguna razón para hacerlo) y podríamos evitarnos así posibles problemas, evitamos que se “hagan experimentos” con nuestra aplicación web.

Los atributos que yo añado a la petición son usados para dar el mensaje correspondiente en la jsp a la que se redirige, por lo tanto vosotros hacer caso solo al texto de los mensajes.

Y ahora nos falta ya por concretar como obtener los campos de texto y como guardar la imagen en disco que tal como aparece en el Servlet aparece simplificado al aparecer en una única línea, pero claro, hay que ver lo que hace esa línea.

Para el caso del texto veremos que podemos obtener un InputStream del Part del formulario y podemos leerlo por ejemplo con la clase Scanner de Java. La única diferencia entre obtener el texto de un campo de texto y un textarea será que tenemos que mantener los saltos de línea para el segundo como veremos ahora. Mientras que en un campo de texto solo habrá una línea. Otro apunte importante sería especificar la codificación para evitar errores con caracteres como tildes, eñes o similares. Por último decir que observeis como se abren y se cierran los objetos de tipo Scanner asegurándonos de que se cierren siempre ocurra o error o no.

public static String getcontentPartText(Part input) {
		Scanner sc = null;
		String content = null;
        try {
            sc = new Scanner(input.getInputStream(), "UTF-8");
            if (sc.hasNext()) {
                content = sc.nextLine();
            } else {
                content = "";
            }
            return content;
        } catch (IOException ex) {
            Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
			content = null;
        }finally{
			sc.close();
		}
		return content;
    }

    public static String getContentTextArea(Part input) {
		StringBuilder sb = null;
		Scanner sc = null;
        try {
            sc = new Scanner(input.getInputStream(), "UTF-8");
            sb = new StringBuilder("");
            while (sc.hasNext()) {
                sb.append(sc.nextLine());
                sb.append("\n");
            }
        } catch (IOException ex) {
            Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
            sb = null;
        }finally{
			sc.close();
		}
		if (sb == null){
			return null
		}else{
			return sb.toString();
		}
    }

Bueno, y ahora ya solo nos faltaría ver como guardar la imagen en disco, como hemos dicho obteniendo el InputStream del Part del formulario (que ya lo obtuvimos en el Servlet y se lo pasamos ahora a este método estático) y también asegurándonos de cerrar los flujos de datos en todos los casos de error y de éxito.

public static boolean guardarImagenDeProdructoEnElSistemaDeFicheros(InputStream input, String fileName)
            throws ServletException {
        FileOutputStream output = null;
        boolean ok = false;
        try {
            output = new FileOutputStream(fileName);
            int leido = 0;
            leido = input.read();
            while (leido != -1) {
                output.write(leido);
                leido = input.read();
            }
        } catch (FileNotFoundException ex) {
            Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
        } catch (IOException ex) {
            Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
        } finally {
            try {
                output.flush();
                output.close();
                input.close();
                ok = true;
            } catch (IOException ex) {
                Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, "Error cerrando flujo de salida", ex);
            }
        }
        return ok;
    }

Hasta aquí creo que no se me queda ningún aspecto por cubrir, únicamente añadir alguna anotación. Comentar que sería interesante para administrar las imágenes guardar sus nombres en una base de datos haciéndolas corresponder con productos por ejemplo en el caso de una tienda. Y aspectos a corregir de mi modo de hacerlo en el proyecto de la tienda sería guardar las imágenes con extensión, puede ser que no todos los navegadores muestren la imagen correctamente, también sería interesante guardar las imágenes con nombres normales y no con códigos, esto último más que nada para el SEO (Search Engine Optimization), debido a que con nombres normales las imagenes se indexarán mejor en los buscadores.

Ahora ya si que he dicho todo lo que tenía que decir y se han cubierto todos los aspectos sobre el tema. Espero que os sea de utilidad esta guía y como siempre digo estoy abierto a dudas sugerencias o lo que os haga falta.

Fallece Steve Jobs

Juan — Thu, 06 Oct 2011 10:01:21 +0000

Hoy según me he levantado por la mañana me he llevado una sorpresa en mi recorrido habitual de noticias por la web. Ha fallecido Steve Jobs esta noche. Una desagradable sorpresa sin duda alguna, el mundo ha perdido una gran persona.

Yo personalmente llevo ya un año manejando un MacBookPro y desde entonces estoy más pendiente de las noticias del mundo apple. Steve Jobs sin duda alguna fue un gran visionario y es el responsable de que hoy hagamos muchas cosas de manera totalmente distinta a como las solíamos hacer. Ha sido un gran emprendedor.

Desde aquí mi más sincero pésame por la pérdida de una gran persona y visionario como dice su sucesor en el cargo Tim Cook.

“Si vives cada día como si fuera el último, algún día acertarás… Cada día me miro al espejo como si fuera el último” Steve Jobs 2005 (Stanford)

En la página de la compañía le rinden homenaje.

Artículos más comentados

Ejemplo Java EE: Una tienda Online

Juan — Wed, 21 Sep 2011 21:22:30 +0000

Continuando con la presentación de seguridad en aplicaciones web, aplicado especialmente a Java EE voy a presentar un proyecto que he llevado a cabo este año, un proyecto que se podría acercar bastante a un ejemplo real con Java EE. Una tienda Online.

El proyecto comenzó siendo una asignatura de la universidad, pero conforme fue avanzando me fui involucrando más en ello y fue adquiriendo unas dimensiones que fácilmente acercarían a la aplicación a algo cada vez más orientado a algo real.

Al acabar el curso el profesor de la asignatura, Abraham Otero Quintana me propuso perfeccionar el proyecto con la intención de que fuera útil a mucha más gente, que fuera un ejemplo más avanzado de lo que se suele encontrar en los manuales.

La aplicación

El proyecto consiste en una aplicación web Java EE que cumple con las funciones de una tienda online. Consiste en una web en la que los usuarios pueden adquirir una serie de productos y posteriormente realizarán el pago (no se ha implementado ninguna pasarela de pago). Los usuarios de la tienda podrán ser usuarios sin registrar o se podrán registrar en la aplicación, lo que les evitará tener que rellenar sus datos; a la vez que les permitirá dejar comentarios sobre los productos.

Como cualquier aplicación del estilo que se precie dispone de una zona de administración únicamente accesible a usuarios con derechos de administración. En dicha zona se podrá gestionar los productos en venta, los usuarios de la aplicación registrados y también consultar el historial de ventas, con el que se generan una serie de gráficas estadísticas sobre las ventas; por último será posible gestionar los comentarios de los productos. Las características están más detalladas en la documentación.

En detalle

La aplicación basa su persistencia en el patrón DAO, por lo que es posible implementar varios métodos de persistencia. Por defecto se han implementado la persistencia contra bases de datos (MySQL) y persistencia contra ficheros serializados en disco.

Durante el desarrollo de la aplicación se ha prestado especial atención a varios aspectos: la seguridad, la concurrencia y finalmente un especial cuidado en la detección de fallos y errores en el funcionamiento del sistema.

En el aspecto de la seguridad nos encontraremos con que toda información enviada por el usuario es validada mediante una librería de seguridad (ESAPI), observaremos también que todo el sistema de URLs está preparado para que solo sea posible acceder a las páginas de la manera que se espera y no de otra manera. Encontraremos más información sobre las medidas tomadas en la documentación del proyecto.

En lo referente a la concurrencia se han hecho las clases encargadas de la persistencia siguiendo el patrón de diseño Singleton para que no sea posible tener más de una instancia de esa clase. En el caso de la persistencia contra ficheros se han tomado las medidas necesarias para asegurar que los archivos no sean corrompidos realizando escrituras simultáneas; así como en el caso de la persistencia contra bases de datos se ha usado un nivel de aislamiento adecuado para evitar la lectura de datos confirmados (READ COMMITED). Es de especial interés en lo que a concurrencia se refiere la manera en la que se hace la compra de un carrito y se disminuyen las unidades en el almacén.

Recursos

He decidido publicar el código fuente completo en un repositorio de google code, también dejo las sentencias SQL necesarias para crear la base de datos. He realizado también un escrito como documentación en el que se puede observar el funcionamiento más en detalle de la aplicación. Por último he realizado un videotutorial en el que se explica desde cero como montar la aplicación y todo lo necesario para que esta funcione.

Espero que os haya gustado y os haya ayudado este ejemplo de programación con Java EE. La publicación es totalmente desinteresada y con fines didácticos; si alguien estuviese interesado en utilizarlo para algún otro fin o seguir trabajando en ello me gustaría que me lo comunicase y se podrían publicar las mejoras.

Estoy abierto a cualquier duda al respecto ya sea con un comentario, contactando conmigo mediante el formulario de contacto o mediante los medios que se indican en la documentación o en Twitter.

Actualización: El artículo ha sido publicado en JavaHispano por Abraham Otero. Creo que es interesante ver los comentarios que se han publicado allí, entre otras cosas por anotaciones interesantes que se han hecho y que se hagan.

Fotografía Juan Díez-Yanguas » Informática

Spotbros: Un ejemplo de como hacer las cosas bien

Artículos más comentados

JRebel: Stop Redeploying

También te puede interesar:

Vanadium: Validación de formularios con JQuery

También te puede interesar:

Tienda Online Java EE: Solucionada validación ajax en formulario de registro

También te puede interesar:

Java EE: Seguridad en aplicaciones web (II). Evitando Inyección SQL y XSS con ESAPI

También te puede interesar:

Tutorial ANT: Uso con librerías externas y generadores JFlex y CUP

También te puede interesar:

Java EE: Seguridad en aplicaciones web (I)

También te puede interesar:

Java EE 6: Subida de imágenes al servidor (Servlet 3.0)

También te puede interesar:

Fallece Steve Jobs

Artículos más comentados

Ejemplo Java EE: Una tienda Online

También te puede interesar: