domingo, 24 de agosto de 2008

JQuery

Cada vez que pienso en desarrollar una aplicación RIA lo primero que se me viene a la mente es Flex. Pero siempre existen los casos en los cuales el cliente no desea que su aplicación dependa de si sus usuarios tengan o no instalado alguna versión determinada del "Flash Player" en sus navegadores. Para estos casos, mi segunda opción es ZK, pero nuevamente existe el problema de que a algunos cliente nos les gusta aventurarse en frameworks no muy conocidos (no muy conocidos por el) y prefieren más bien que sus sistema sea desarrollado utilizando algún otro framework o estándar mas conocido por la industria.

Es en estos escenarios donde recurro a mi querido (y también odiado) JSF. Hace ya bastante tiempo que no volvía a meter las manos con JSF, pero gracias a dios, hoy en día todo es mucho más fácil, si es que utilizamos “Facelets” y todo el poder que nos entrega “Spring Faces”.

Hasta el momento todo está bien, pero en este último caso, me vuelvo a encontrar con el mismo problema de siempre. El cliente quiere un sistema de ensueños!!!. Que todo sea “Drag-and-Drop”, full Ajax, mucho efecto visual, etc…..

Claro, si hablamos de JSF, podría utilizar RichFaces, IceFaces, MyFaces o alguna otra batería de componentes. Pero que pasa en los casos en que necesito alguna funcionalidad especial que no esté implementada dentro de este conjunto de componentes?.

Buscando una opción, recordé haber leído que hoy en día, muchos consideran a JQuery como una de las mejores librerías Javascript del momento. Así que decidí ver que tanta maravilla es esta tan bullada librería, y aunque no me considero un fanático de Javascritp (muy por el contrario), la única palabra que se me ocurre para expresar el sentimiento que me produjo es GUUUUAAAAAUUUUUUU!!!!!!!.

Mi objetivo es compartir algunos conceptos básicos que he podido desarrollar gracias al libro “Learning Jquery - Better Interaction Design And Web Development With Simple Javascript Techniques”.

Si alguien está interesado en aprender Javascript, le recomiendo el libro gratuito de Javier Eguíluz Pérez que pueden descargar desde aquí.

JQuery es una librería JavaScript rápida y concisa, que simplifica la tediosa tarea de recorrer documentos HTML (DOM), manejar eventos, ejecutar animaciones y agregar interacciones con Ajax.

Para utilizar JQuery, solo necesitamos descargar la librería y en cada página que necesitemos utilizarla, simplemente definir:



Una de las principales ventajas, además de ahorrarnos la escritura de bastante código (principalmente útil para los que no somos muy expertos en Javascript), es que nos permite manipular la página apenas se haya construido el árbol DOM de esta, en comparación con las funciones de Javascript, las cuales esperan a que se carguen todos los elementos de la página (incluyendo todas las imágenes).

Algunas de las principales ventajas que nos aporta esta librería son:

  • Nos ahorra muchas líneas de código.
  • Nos hace transparente el soporte de nuestra aplicación para los principales navegadores web.
  • Nos provee de un mecanismo para la captura de eventos.
  • Provee un conjunto de funciones para animar el contenido de la página en forma muy sencilla.
  • Integra funcionalidades para trabajar con AJAX.

El primer paso será descargarnos la última versión de JQuery desde aquí y dejarla dentro de nuestro proyecto.

Para los siguientes ejemplos he renombrado el archivo a “jquery.js” y lo he dejado guardado dentro de la carpeta “js” de mi aplicación web.

Para entender mejor como nos puede ayudar JQuery a ahorrar muchas líneas de código, nada mejor que un ejemplo comparativo “Sin JQuery” y “Con Jquery”.








Ya a simple vista podemos ver que a diferencia de la forma tradicional, con JQuery nos basto simplemente un par d líneas de código para lograr la misma funcionalidad. Pero, como trabaja JQuery?.

La función principal de esta librería se llama “$”, a la cual le podemos pasar distintos valores, y la que a su vez retorna un objeto del tipo JQuery .

Si vemos el código del archivo “ejemploBasicoJQuery.js”, podremos observa que el primer método que estamos llamando es a “ready”:



Este método recibe como parámetro el nombre de una función, la que se ejecutara cuando todos los elementos de la página estén cargados.

Dentro de la función “inicializarEventos”, nuevamente utilizamos la función “$” para crea un objeto de la clase JQuery asociada a un botón de la pagina HTML. Para lograr esto, a la función “$” le pasamos el “id” del botón al cual la queremos asociar precediéndolo por el caracter "#".

Por último, llamamos al método click, pasándole como parámetro el nombre de la función que se ejecutará al presionar ese botón.

En el caso de que queramos asociar algún elemento de una página HTML a la función “$”, simplemente seguimos la sintaxis:

$(“nombre_elemento_HTML”)

El único problema con este tipo de función, es que estaremos referenciando a los de este tipo contenidos en nuestra página HTML. Entonces, como podemos discriminar sobre que elemento de la pagina se efectuó alguna acción?. Simplemente llamando a la función "$(this)".

Otra característica muy importante de JQuery, es que nos permite tener acceso a los selectores CSS de los elementos contenidos dentro del árbol DOM.

Veamos un ejemplo que muestre todos los tópicos mencionados hasta el momento:





Además de tener acceso a los selectores CSS, también podemos tener acceso a las clases que tengamos definidas dentro de nuestra página CSSHTML simplemente llamando a la función:

$(“.nombre_clase_css”)

Si queremos obtener el texto de un elemento, simplemente llamamos al método "text()". Por ejemplo, si tenemos el párrafo:



Para obtener el texto llamaremos a la función "text()" del elemento “p”:



En cambio, si queremos modificar el texto contenido dentro del elemento, llamaremos nuevamente al método "text()", pasándole como parámetro el nuevo texto:



Otros métodos importantes dentro de JQuery, son aquellos que nos permiten manipular los atributos de los elementos de nuestra página HTML. Estos son:

  • attr(nombre_atributo)
  • attr(nombre_ atributo, valor)
  • removeAttr(nombre_ atributo)

Por ejemplo:





Eventos

Algunos de los eventos más importantes dentro de JQuery son:

mouseover/mouseout: Estos eventos son equivalentes a los eventos onmouseover y onmouseout de Javascript. El primero de estos se ejecuta cuando ponemos la flecha del mouse sobre un elemento HTML y el segundo cuando sacamos la flecha del elemento.

hover: Como los eventos mouseover y mouseout son comúnmente usados, existe el evento hover que recibe dos parámetros:

$(elemento).hover([función de ingreso del mouse],[función de salida del mouse])

La primera función se ejecuta cuando ponemos la flecha del mouse sobre un elemento HTML y el segundo cuando sacamos la flecha del elemento.

mousemove: Este evento se ejecuta cuando se mueve la flecha del mouse dentro del elemento HTML respectivo.

mousedown/mouseup: El primer evento se ejecuta cuando presionamos alguno de los botones del mouse y el segundo cuando dejamos de presionar el botón.

dblclick: Este evento se ejecuta cuando se presiona dos veces seguidas el botón izquierdo del mouse sobre un elemento HTML.

focus: Este evento ejecuta cuando se activa el control. Podemos capturar el evento focus de un control de tipo text, textarea, button, checkbox, fileupload, password, radio, reset y submit.

blur: Este evento se ejecuta cuando se pierde el foco el control. Podemos capturar el evento blur de un control de tipo text, textarea, button, checkbox, fileupload, password, radio, reset y submit.


Efectos

Otro concepto importante son los efectos, entre los que destacan:

show/hide: Permiten ocultar y mostrar elementos HTML, asociándoles una pequeña animación (que se oculte o muestre lentamente).

fadeIn/fadeOut: El primer efecto hace aparecer los elementos HTML con opacidad y el segundo lo decolora hasta hacerlo desaparecer (reduce la opacidad del elemento en forma progresiva).

fadeTo: Permite modificar la opacidad de un elemento, llevando la opacidad actual hasta el valor que le pasamos como parámetro. Tambien se le puede la velocidad de la transición (en milisegundos).

toggle: Permite cambiar de estado la visibilidad del elemento HTML; es decir si está visible pasa a oculto y si se encuentra oculto pasa a visible.


Si quieren ver todas las funcionalidades de JQuery, les recomiendo visitar esta página.

Además, como toda buena librería, esta ya cuenta con un conjunto de plugins que extienden y facilitan aun más el uso de JQuery. En esta página encontraran un listado de los 10 plugins más populares, entre los que destaca JQuery UI.

Después de todo lo visto, creo que me quedare con “RichFaces” en el en mundo JSF, debido a que se integra fácilmente con JQuery.

sábado, 23 de agosto de 2008

Inyección de SQL (SQL Injection)

Uno de los temas a los cuales puede asistir en las “Primeras Jornadas Latinoamericanas de Arquitectura de Software” fue “Seguridad y Arquitectura de Software”, el cual fue presentado por Juan Carlos Herrera.

Dentro de los tópicos de la presentación, se menciono la "Inyección de SQL", como uno de los problemas que comúnmente se presentan en la seguridad del desarrollo de software. Pero….. que es la inyección de SLQ?.

Se define la inyección de SQL, como el proceso de insertar código SQL dentro de otro código SQL, con el objetivo de alterar el funcionamiento normal de una sentencia SQL.

Este problema no se debe a que el lenguaje de programación que estemos utilizando presente este problema de seguridad, sino mas bien, gracias a nosotros, los desarrolladores, que en la mayoría de los casos, tenemos un escaso o nulo filtrado de los datos en el proceso de validación de estos dentro de nuestras aplicaciones, lo que permite a un atacante, insertar (o mejor dicho “inyectar”) código SQL dentro de las variables de nuestra aplicación, las que utilizamos para realizar consultas SQL.

Pero como sucede esto? Por qué sucede esto? Donde está el problema?

Imaginemos que estamos desarrollando un software para una institución financiera (reconozco que no soy muy original para mis ejemplos), en donde la seguridad es vital. Como todo sistema bancario, este dispone de una base de datos donde almacena la información de sus clientes, sus cuentas, las transacciones bancarias, etc. Entonces, si quisiéramos consultar la información de los tipos de cliente (persona o empresa), podríamos utilizar una sentencia SQL como esta:

SELECT * FROM cliente WHERE tipoCliente=’tipoCliente’;

Donde la variable ‘tipoCliente’ contiene el tipo de cliente que es para el banco (persona o empresa).

Con esta simple consulta podríamos obtener todos los clientes de tipo “persona” que tenga el banco.

Imaginemos que además de consultar la información de un cliente por su tipo, queremos filtrar la información por comuna. Es decir, queremos ofrecerle al usuario la posibilidad de elegir, el tipo de cliente que quiere ver asociado a una determinada comuna.

Para esto, podríamos construir un servlet que procese esta información y cuyo resultado se despliegue en la página “consultaCliente.jsp”. Entonces, si el usuario realizaría una petición HTTP a nuestra JSP, pasándole los valores de la consulta por GET:

http://www.mibanco.cl/consultaCliente.jsp? tipoCliente =persona&comuna=macul

El servlet que procese esta petición, tomara los parámetros enviados por el usuario y ejecutaría la siguiente consulta SQL sobre la base de datos:

SELECT * FROM cliente WHERE tipoCliente=’persona’ AND comuna='macul';

Una vez ejecutada la consulta, los resultados obtenidos serian desplegados en la página “consultaCliente.jsp”.

Lo importante de todo esto, es que en algún punto de nuestro código, nosotros construimos la sentencia SQL en base a los valores enviados por el usuario. Es decir, si por algún motivo, al usuario se le ocurre enviarnos el valor “cualquiercosa” como comuna, nada se lo impedirá, y nuestra aplicación construirá la siguiente sentencia SQL:

SELECT * FROM cliente WHERE tipoCliente=’persona’ AND comuna='cualquiercosa';

La pregunta es, donde está el problema en todo esto?......al parecer, no existe ningún problema, porque en el peor de los caso, esta consulta no devolverá nada, ya que la comuna “cualquiercosa” no existe. Pero…….¿qué pasaría ahora si en vez de ingresar un valor cualquiera, el usuario se le ocurriera ingresar como comuna parte de una sentencia SQL?.

Por ejemplo, que sucedería en el caso de que el usuario enviara la siguiente consulta HTTP:

http://www.mibanco.cl/consultaCliente.jsp? tipoCliente =persona&comuna= %20OR%20%22=

Ahora nuestra aplicación construiría la siguiente consulta SQL:

SELECT * FROM cliente WHERE tipoCliente=’persona’ AND comuna =’’ OR ''=’’;

Estos si es un problema!!!! Estamos permitiendo que el usuario pueda manipular la sentencia SQL. Nuestra sentencia estaría diciéndole a la base de datos que le entregue todos los clientes de tipo persona y cuya comuna sea igual a ‘ ” ‘ o la expresión ‘=’ sea verdadera. Que en pocas palabras, le está diciendo a la base de datos que le entregue todos los clientes no importando cual sea la comuna.

Como podemos ver, el usuario está logrando alterar nuestra consulta para obtener un resultado no esperado por la aplicación. En este caso, mostrar todos los clientes de nuestro banco sin importar su comuna.

A este proceso se le conoce como”Inyección de SQL”. Si bien este pequeño ejemplo no implica un mayor “peligro” para nuestro sistema, no podemos pasar por alto que hay una vulnerabilidad grave en nuestro sistema, que podría permitir a un atacante con un poco más de conocimiento hacer otro tipo de inyecciones más perjudiciales para nuestra aplicación.

Qué pasaría con un usuario más astuto? Imaginemos que ahora nuestro usuario tiene un alto conocimiento de SQL (algún miembro del JUG Chile), y quiere validar si nuestro sistema presenta algún problema de seguridad frente a ataques de tipo “Inyección de SQL”. Entonces, no haya nada mejor, que enviar ciertos parámetros por la URL que le permitan obtener los datos de otra tabla, como por ejemplo, la tabla “cuentas”, que contiene toda la información de las cuentas bancarias de nuestros clientes.

Entonces, esta vez nuestro usuario realiza la siguiente consulta:

http://www.mibanco.cl/consultaCliente.jsp? tipoCliente =persona&comuna=%20UNION%20SELECT%20*%20FROM%20cuentas%20WHERE%20%22=

Entonces, nuevamente nuestro servlet que procesa esta petición, tomara los parámetros enviados por el usuario y ejecutara la siguiente consulta SQL sobre la base de datos:

SELECT * FROM clientes WHERE tipoCliente='persona' AND comuna='' UNION SELECT * FROM cuentas WHERE ''='';

Ahora si estamos en serios problemas!!!!!. El usuario a logrado obtener a través de esta consulta, todos los datos de las cuentas bancarias registradas en nuestra base de datos.

Entonces, nuevamente volvemos al punto inicial. Sera que el lenguaje que estamos utilizando para programa nuestro sistema presenta este tipo de problemas de seguridad? O será acaso un problema de nuestra base de datos?; y la pregunta principal….¿Puedo yo, como desarrollador de este sistema, evitar de alguna manera este tipo de ataques?.

Si analizamos nuestra aplicación, nos encontraremos que el principal problema radica en la nula verificación de los datos enviados por el usuario antes de realizar la consulta SQL a la base de datos.

Pero qué tipo de verificación?....bueno, simplemente validar que dentro de los valores enviados por el usuario, estos no contengan código SQL que permitan la manipulación de nuestra sentencia SQL.

Si analizamos nuestro ejemplo, los valores que tendríamos que verificar, son “tipoCliente” y “comuna”. Son estos valores, los que tendríamos que validar, verificando que no contengan caracteres especiales, como por ejemplo comillas, que puedan servir al usuario para inyectar código SQL en la consulta.

En este caso, nos bastaría con verificar que el “tipoCliente” y la “comuna”, sólo contengan letras, sin ningún carácter especial.

Lo importante de todo esto, es que el problema de la seguridad de nuestro sistema (debido a la inyección de SLQ), radica principalmente en la verificación de datos dentro de nuestro sistema. Por lo tanto, una solución, es filtrar siempre la entrada del usuario, de manera que atacante, nunca pueda inyectar código SQL en ningún lado dentro de nuestra aplicación.

Algunas técnicas, comúnmente recomendadas para la filtración de los valores enviados por el usuario son:

  • Limitar, siempre que se pueda, el tamaño del valor ingresado. De esta manera, limitamos la cantidad de código SQL que un atacante puede inyectar. En especial si se trata de una consulta anidada.
  • No permitir, o en su defecto escapar, todos los caracteres que puedan llegar a ser usados como parte de una inyección SQL: comilla simple (’), punto y coma (;) y caracteres de comentario (/* */ y –).
  • Filtrar con expresiones regulares todo lo que ingrese el usuario. Por ejemplo, en un formulario de registro, el campo mail sólo debería aceptar letras en minúsculas, números y un arroba. Al igual que en un número de teléfono sólo deberían aceptarse números.

Otros consejos, que no se encuentran relacionados con al verificación de los valores son:

  • Realizar las consultas de la aplicación, utilizando un usuario, con la menor cantidad de privilegios posible dentro de la base de datos. De modo que si un atacante, pudiera saltarse de algún modo la verificación de los valores e inyectar código en alguna de nuestras consultas, los daños se reduzcan al no tener suficientes privilegios.
  • Realizar la verificación de los valores ingresados por el usuario, en todas las capas de la aplicación. Algunos desarrolladores por ejemplo, hacen una sola verificación dentro de la capa de presentación, utilizando JavaScript. Esto, puede ser fácilmente evitado, enviado los valores directamente a través del navegador.
  • No mostrar los mensajes de error devueltos por la base de datos. Para un atacante podría serle muy útil esta información, en especial para hacer “Blind Injection”.
  • Usar Prepared Statements: Esta es una de las mejores soluciones que se pueden utilizar para evitar este tipo de ataques, ya que prácticamente son inmunes a las inyecciones SQL.

Una explicación más detalla de la inyección de SQL y artículos relacionados con el tema, la pueden encontrar aquí.

Pero como todo problema en el mundo Java, siempre existe alguien con una solución. Para este tipo de ataques tenemos el framework HDIV (HTTP Data Integrity Validator).

viernes, 22 de agosto de 2008

Patrones de diseño GoF (Gang of Four)

En anteriores post, hemos visto algunos de los patrones que son parte del GOF. Pero como una imagen vale más que mil palabras, aquí les dejo este link en donde podrán encontrar un excelente PDF con los diagramas UML de los principales patrones.

Esta no es la única opción, ya que también existe el poster de Head Fisrt Design Patterns, pero que a diferencia de la opción anterior, esta utlima es pagada.

Este es un poster que Cerebro no puede dejar de tener!!

jueves, 21 de agosto de 2008

SCWCD - El descriptor de despliegue web.xml

El archivo web.xml proporciona la configuración y el despliegue de información para los componentes web que conforman una aplicación.

Este archivo debe residir en el directorio WEB-INF dentro del contexto de la jerarquía de directorios que existen para una aplicación Web. Por ejemplo, si la aplicación esta empaquetada en el archivo WAR "dukechile.war", el archivo web.xml se debe colocar en el directorio “dukechile/ WEB-INF”.

Como todos los archivos de configuración xml, este contiene un esquema que describe el contenido del fichero xml y la descripción de las propiedades que va a utilizar. Dentro de este archivo definiremos la configuración de la aplicación web que estemos desarrollando.

Los elementos del web.xml son:

<web-app>: Es el elemento raíz del fichero xml.

<icon>: Define la ruta para las imágenes asociadas a los iconos pequeño y grande que representan a la aplicación.

<display-name>: Es el nombre que representará a la aplicación dentro de las herramientas del servidor de aplicaciones, no es un nombre funcional.

<description>: Texto descriptivo de la aplicación, que al igual que las dos anteriores propiedades, sólo es representativo.

<context-param>: Permite configurar parámetros de inicialización del contexto de nuestra aplicación web.



<filter>: Permite definir un filtro en la aplicación.



<filter-mapping>: Define un mapeo para aplicar las reglas de un determinado filtro a una URL.



<listener>: Permite definir una clase oyente, la que puede escuchar eventos relacionados al clico de vida de la aplicación o modificaciones de un objeto.



<servlet>: Permite definir la configuración de nuestros servlets.



<servlet-mapping>: Permite relacionar los servlets que hemos declarado con las URL que van a escuchar.



<session-config>: Permite definir el timeout de la sesión en minutos.



<mime-mapping>: Permite definir una relación entre las extensiones y los tipos mime.



<welcome-file-list>: Permite definir los ficheros de bienvenida de la aplicacion.



<tag-lib>: Permite definir las librerías de etiquetas de los ficheros JSP.



<jsp-property-group<: Permite definir propiedades para un conjunto de JSP que cumplan un patrón.



<error-page<: Permite asociar errores HTML y excepciones lanzadas por nuestra aplicación a páginas de error personalizadas para la aplicación.



<resource-ref<: Permite declarar recursos externos que nuestra aplicación va a utilizar. Por ejemplo, una conexión a una base de datos.



<resource-env-ref<: Permite declarar recursos externos que nuestra aplicación va a utilizar. Este elemento es una nueva variación del elemento añadido en Servlet 2.4 que es más simple de configurar para recursos que no necesitan información de autenticación.



<security-constraint<: Permite proteger áreas de la aplicación (o la aplicación completa), asociándolas a roles que deben tener los usuarios para poder acceder. Estos usuarios y roles son los declarados en tomcat-users.xml (para el caso de Tomcat).



<login-config<: Permite configurar el tipo de login que se requerirá al entrar en un área protegida previamente declarada.



<security-role<: Permite definir los roles de usuarios que se van a utilizar en la aplicación.



<env-entry<: Permite declarar una posible entrada al entorno (environment) de la aplicación.



<ejb-ref<: Permite definir una referencia a un EJB.



<ejb-local-ref<: Permite definir una referencia a un EJB Local.



<distributable<: Permite definir que la aplicación puede correr en un ambiente cluster.

miércoles, 20 de agosto de 2008

SCWCD - Seguridad en aplicaciones Web

Uno de los tópicos que se debe estudiar para la certificación SCWCD (Sun Certified Web Component Developer) son los mecanismos de seguridad en las aplicaciones Web.

Mecanismos de seguridad

La seguridad en los servlets se reduce a cuatro conceptos principales:

  • authentication: El proceso de autenticación es el encargado de determinar que el interesado en acceder los recursos es realmente quien dice que es. Lo más común es hacer que el usuario o la aplicación envié un password que lo identifica.
  • authorization: Es el proceso por el cual se restringe el acceso a ciertos recursos a un conjunto de clientes. En realidad, lo que se define es un conjunto de roles que pueden acceder a ciertos recursos y se asocia cada usuario a uno o más roles.
  • data integrity: Es el proceso que asegura que los datos que se reciben (tanto el cliente como el servidor) no han sido corrompidos. Generalmente se usan algoritmos de encriptación para lograr esto.
  • confidentiality: Es el proceso que intenta asegurar que solamente los clientes autorizados reciban la información. La manera de lograr esto puede ser a través del uso de claves públicas/privadas.

Tipos de autentificación definidos

La especificación de servlet ofrece cuatro tipos de autentificación:

  • BASIC: Este es el método más simple, pero el más inseguro. Cuando usamos este tipo de autenticación, se abre una ventana en el browser del cliente para que este ingrese el usuario y el password. El password se envía al servidor codificado en Base64.
  • FORM: Este método es similar a BASIC, pero utiliza un formulario provisto por el programador. Este formulario tiene que cumplir los siguientes requisitos:
  1. El atributo “action” debe ser “j_security_check
  2. El casillero de ingreso del usuario debe llamarse “j_username
  3. El casillero de ingreso del password debe llamarse “j_password

  • CLIENT-CERT: En este método se usan certificados digitales. El browser debe tener instalado el certificado para que la comunicación se pueda establecer.
  • DIGEST: La autenticación también es hecha utilizando usuario y password, pero el password es enviado encriptado de una forma mucho más segura (por ejemplo, utilizando HTTPS client authentication).

Autorización

El primero paso es definir los roles que se encontraran definidos dentro de nuestro sistema. Para el caso de Tomcat, estos se definen en el archivo tomcat-users.xml. Dentro de este archivo, cada usuario tiene asignado un usuario y password; y puede estar asociado a uno o más roles.



El siguiente paso es relacionar los roles definidos en el archivo tomcat-users.xml, con los roles a utilizar dentro del sistema. Para esto deberemos utilizar los elementos <security-role> y <role-name> dentro del archivo web.xml.



Una vez definidos los roles, se procede a establecer “declarativamente” el acceso a un conjunto de recursos en combinación con los métodos, a los cuales tendrán accesos determinados roles. El elemento principal es el <security-constraint>.



Donde:

  • El elemento <web-resource-name> es obligatorio y utilizado principalmente por los IDEs.
  • El elemento <url-pattern> define el recurso al cual se limitara el acceso. Al menos se debe definir a lo menos un <url-pattern>.
  • El elemento <http-method> describe el método HTTP que será restringido para acceder al recurso definido en los <url-pattern>. Si no se define ningún <http-method>, entonces se restringirá el acceso a todos los métodos HTTP.
  • El elemento <auth-constraint&gt; es opcional y permite definir cuales roles pueden llamar a los métodos HTTP restringidos por los elementos <http-method&gt;

Para permitir el acceso a todos los roles, se debe definir el elemento <auth-constraint> de la siguiente forma:



O también de la forma:



En el caso de que se quiera bloquear el acceso a todos los roles, se deberá definir el <auth-constraint> de la siguiente forma:



Es importante tener en cuenta que se puede tener más de un elemento <web-resource-collection> dentro de un <security-constraint>. En este caso, el elemento <auth-constraint> se aplica a todos los <web-resource-collection> definidos dentro de un <security-constraint>.


Autentificacion

Anteriormente mencionamos que la especificación de servlet ofrece cuatro tipos de autentificación: BASIC, FORM, CLIENT-CERT y DIGEST.

Cada uno de estos tipos se puede definir en el web.xml de siguiente forma:



Un punto importante es que de los cuatro tipos de autentificación, el tipo DIGEST es el único que es opcional para los contenedores JEE.

Modos de transporte

La especificación también define tres modos para indicar la seguridad del transporte de los datos a través de la Web.

  • NONE: Ningún tipo de cifrado, simplemente HTTP.
  • CONFIDENTIAL: Define la confidencialidad de los datos. Es decir, que nadie pueda ver ni modificar los datos que se envían.
  • INTEGRAL: Define la integridad de los datos. Es decir, que aunque alguien pueda ver lo que se envía, se garantice que los datos no se modifiquen por el camino.



El metodo isUserInRole()

La clase “HTTPServletRequest” tiene tres métodos que están asociados al manejo de la seguridad de manera “programática”, uno de estos es el método “isUserInRole”.

A través del método “isUserInRole()”, en vez de manejar el acceso a nivel de método HTTP, ahora podremos autorizar el acceso a una parte del código de nuestro método basados en los roles del usuario.

Antes de que se llame al método “isUserInRole()”, el usuario necesita estar autenticado. En el caso de que llame al método sobre un usuario que no ha autenticado, el contenedor retornara “false”.

En el caso de que este autenticado, el contenedor toma el argumento del método y compara este con los roles definidos para el usuario en el “request”.

Si el usuario es mapeado a este rol, el contenedor retornara “true”.

Por ejemplo, dentro del código en el servlet:





El elemento <security-role-ref> permite relacionar un <role-name> definido “programáticamente” (en el servlet) con uno que existe en el web.xml.

martes, 19 de agosto de 2008

JMesa

Muchos desarrolladores Web, alguna vez hemos utilizado DisplayTag para la creación de tablas con exportación y paginación automática. DisplayTag es un tag lib que nos permite ahorrar muchas líneas de código.

Ahora disponemos de una alternativa mucho más actualizada y potente llamada JMesa.

Los pasos para agregar JMesa a sus aplicaciones son muy simples.

Descargan JMesa desde aquí y agregan el tld que se encuentra bajo el directorio /jmesa-2.3.3/dist del zip al directorio /WEB-INF/tld de la aplicación.

También deberan agregar los ficheros css, javascript, las imágenes y por supuesto los jar en sus directorios correspondientes. Como JMesa requiere de JQuery, también deberán agregarlo al directorio js ( JQuery lo pueden obtener desde aquí). No importa donde se coloquen los css ni los javascript dado que se configuraran posteriormente. Las imágenes sin embargo tienen que estar en una ruta determinada que ha de coincidir con la del valor de la clave html.imagesPath especificada en el fichero jmesa.properties.

Este último fichero hay que crearlo y referenciarlo en el web.xml:



A continuación, deberán crear el archivo jmesa.properties en el directorio WEB-INF de la aplicación.



Con estos pasos, ya se encuentra listo y configurado. Para utilizarlo hay que definir el namespace de JMesa en nuestra página:



Ahora simplemente definiremos la siguiente línea:



Con estos simples pasos, ya podremos utilizar JMesa dentro de nuestros proyectos.

domingo, 17 de agosto de 2008

El patrón “Cadena de Responsabilidad” (Chain of Responsibility) - Parte VI

Los últimos ataques han sido todo un éxito, cada día se logran nuevas conquistas!!!. Debido a esto, Cerebro se ha visto en la necesidad de aumentar el número de robots dentro de sus tropas. Ahora su ejército se encuentra organizado en una estructura jerárquica, para lo cual ascendió a sus mejores solados a rangos como “General” o “Coronel”.

Con esta nueva estructura será mucho fácil dar órdenes a su ejército, el simplemente dará la orden a su “General Mazinger Z” quien al leer el comunicado decidirá si debe ejecutarla el o deberá derivarla a un sub-alterno; y así sucesivamente en la jerarquía hasta llegar al “Soldado El Galactico”.

Genial…..como siempre este plan es simple……es magnífico……es perfecto…….pero!!!!!!!

Cerebro se ha dado cuenta nuevamente que ha olvidado algo muy importante, su mecanismo de comunicación (implementado con el patrón “Observador”) ya no le sirve. Ahora tiene una estructura jerárquica, y necesita que la orden pase a través de esta estructura hasta el sub-alterno al que se le desee enviar este mensaje. Por lo tanto necesita un mecanismo en el cual el receptor del mensaje pueda no solo ejecutar la orden, sino también poder comunicar esta a su sub-alterno en el caso de que no fuera dirigida a él.

Una solución sería ir replicando el patrón “Observador” en cada uno de sus niveles jerárquicos, pero esta no es la solución más optima..

Debido a todos estos problemas, recurre nuevamente a su gurú “Martin Fowler” y encuentra la solución perfecta!!!!. Cerebro ha visto que el patrón “Cadena de Responsabilidad” (Chain of Responsibility) es ideal para solucionar su problema.



Primero necesitara definir la clase “Mensaje”, la cual contendrá a quien esta dirigida la orden y cuáles son las instrucciones a ejecutar.



Luego, deberá definir la clase abstracta “EjecutarOrdenAltoMando”, la cual deberán extender cada uno de los elementos de su ejército.



Ahora, cada sub-alterno que extienda la clase abstracta, deberá definir un mecanismo que permita discriminar si la orden enviada la debe ejecutar el, o en caso contrario, enviar la orden a su sub-alterno.







Finalmente, será muy fácil para Cerebro enviar un mensaje a su ejército, el simplemente dará la orden a su “General” y listo!!



Cerebro lo ha conseguido nuevamente, ha logrado diseñar un nuevo mecanismo de comunicación para su ejército, continuando su malvado plan………“TRATAR DE CONQUISTAR AL MUNDO!!!!

domingo, 20 de julio de 2008

Introducción a Spring Framework

Spring es un framework open source creado por Rod Johnson, el cual fue inicialmente descrito en su libro “Expert One-on-One: J2EE Design and Development”. El objetivo de Rod Johnson era implementar un framework que permitiese desarrollar aplicaciones empresariales de manera más fácil y rápida, utilizando POJOs (Plain Old Java Object) para lograr cosas que antes eran solamente posibles con EJBs.

Uno de los principales objetivos de Spring es no ser intrusito. Esto quiere decir, que aquellas aplicaciones configuradas para utilizar “Beans” mediante Spring no necesitan depender de interfaces o clases de Spring, obteniendo su configuración a través de las propiedades de sus "Beans".

Este concepto puede ser aplicado a cualquier entorno, desde una aplicación J2EE hasta un applet.

Spring está compuesto por un conjunto características, las cuales están agrupadas en seis módulos principales:



El paquete “Core” es la parte más fundamental del framework ya que provee a este, las características de Inversión de Control (IoC) y Inyección de dependencias (ID). El concepto básico dentro del “Core” es el “BeanFactory”, el cual provee una sofisticada implementación del “Patrón Factory”, que remueve la necesidad generalizada de “Singletons” y nos permite desacoplar la configuración y especificación de las dependencias de nuestra lógica de programación.

El paquete “Context” está construido sobre una solida base provista por el paquete “Core”, el cual proporciona un medio de acceso a los objetos contenidos en el framework de forma tal, que recuerda en cierta medida a la manera en cómo trabaja el registro JNDI. Este paquete hereda algunas características del paquete “Beans” y añade soporte para internacionalización (I18N), propagación de eventos, carga de recursos y la transparente creación de contextos, como por ejemplo, un “Servlet Container”.

El paquete “DAO” provee una capa de abstracción a JDBC, eliminando la tediosa codificación propia de JDBC y el parseo de los códigos de errores específicos de cada proveedor de base de datos. Así también, este paquete proporciona mecanismos de manejo de transacciones tanto programáticamente como declarativamente, cuyo manejo no está restringido a clases que implementen algún tipo de interfaz especial, sino que también está pensado para cualquiera de nuestros POJOs.

El paquete “ORM” provee una capa de integración con las APIs más populares de “Mapeo Objeto-Relacional”, tales como JPA, JDO, Hibernate y iBatis. Usando este paquete nosotros pidremos utilizara cualquiera de estos ORM en combinación con todas las otras características que Spring ofrece.

El paquete “AOP” de Spring, provee una implementación para la programación “Orientada a Aspectos” compatible con el “AOP Alliance” que nos permite definir, por ejemplo, interceptores a un método (method-interceptors) y puntos de corte (pointcuts) para desacoplar limpiamente algunas funcionalidades implementadas en el código que lógicamente deberían conversar por separado.

El paquete “Web” de Spring provee características de integración orientadas a la Web, tales como funcionalidades para la carga de archivos, la inicialización del contenedor IoC usando “Servlet Listeners” y un contexto de aplicación orientado a la web.

El paquete “MVC” de Spring, provee una implementación del patrón MVC (Moldeo-Vista-Controlador) para las aplicaciones web. Spring MVC provee una limpia separación entre el código del modelo de dominio y los formularios web, integrándose a todas las otras características que este framework entrega.

Ejemplo Basico

Para poder comenzar a desarrollar en Spring lo primero que necesitamos es descargarnos la versión 2.5.5 desde www.springframework.org.

En la sección de “download” encontraran tres tipo de archivos a descargar: Spring 2.5.5 (spring-framework-2.5.5.zip), Spring 2.5.5 incluyendo la documentación (spring-framework-2.5.5-with-docs.zip) y Spring 2.5.5 incluyendo todas las dependencias (spring-framework-2.5.5-with-dependencies.zip). Para este ejemplo y los futuros ejemplos, necesitaremos la última de estas tres opciones.

Una vez descargados los archivos, procedemos a crear el proyecto. Para este caso, tenemos varias opciones: podemos utilizar Netbeans 6.x el cual ya incluye soporte para Spring, Eclipse 3.x al cual se le debe instalar Spring IDE o IntelliJ el cual también incluye soporte para Spring.

En este caso utilizare IntelliJ para los ejemplos.

Primero creamos el proyecto seleccionado la opción “File --> New Project…”. Luego seleccionamos la opción “Create Project from scratch” y presionamos el botón “Next”.



A continuación, ingresamos el nombre del proyecto, que para nuestro caso será “SpringBasico” y presionamos el botón “Next”.



Luego, seleccionamos la opción “Create source Directory” y presionamos el botón “Next”.

Por último, seleccionamos que la tecnología deseada para utilizar en el proyecto es “Spring” y presionamos el botón “Finish”. Con lo que se nos construirá la estructura básica de nuestro proyecto.



El único problema, es que la última versión de IntelliJ IDEA solamente tiene soporte hasta la versión 2.0.7 de Spring, razón por la cual necesitaremos cambiar la librería “Spring.jar” por la versión que nosotros descargamos.

Para esto, nos posicionamos sobre el proyecto, presionamos el botón derecho del mouse y seleccionamos la opción “Module Settings”.



Luego, en las opciones de “Project Settings” seleccionamos “Libraries”. Es aquí donde cambiaremos el nombre de nuestro paquete de librerías y modificaremos el “Spring.jar”.

El primer paso será cambiar el nombre del paquete “Spring-2.0.7” por “Spring-2.5.5”. Luego, seleccionamos la ruta del archivo “Spring.jar” y presionamos el botón “Detach”. Por último, presionamos el botón “Attach Classes…”, seleccionamos el archivo “Spring.jar” que se encuentra en la carpeta “dist” de la versión que descargamos anteriormente y presionamos el botón “Ok”.

Para finalizar, presionamos el botón “Apply” para que confirme y actualice todos los cambios, y presionamos el botón “OK”.

El último cambio lo deberemos realizar sobre el archivo “spring-config.xml”. Como IntelliJ solamente tiene soporta para Spring 2.0.7, la definición XSD de este archivo es para la versión 2 de Spring. Por esta razón, deberemos cambiar esta por la versión 2.5.



Para nuestro primer ejemplo, desarrollaremos una idea simple que nos permita ver algunos de los beneficios básicos de Spring.

Imaginemos que necesitamos construir un robot, al cual le ensamblaremos un par de piernas, un par de brazos y una cabeza. Una primera propuesta a nuestro problema sería la siguiente:











El problema con esta implementación es que el código esta “Altamente Acoplado”. Que sucedería si decidimos cambiar la implementación de un brazo? No solamente tendríamos que modificar la clase “BrazoImpl”, sino también la clase “RobotImpl”. Es aquí donde la inversión de control “IoC” y la inyección de dependencias “ID” nos ayudan (más información de IoC y ID la pueden encontrar aquí).

El primer cambio que tendremos que realizar al código, es que cada pieza del robot deberá implementar una interfaz, con lo cual estaremos definiendo un contrato para cada una de estas piezas, y en el caso de que necesitemos diseñar un nuevo brazo o una nueva pierna, simplemente deberemos implementar la interfaz asociada al tipo de pieza.

















Pero quien se encargara de ensamblar el robot? Aquí es donde Spring entra en acción. En el archivo “spring-config.xml” definiremos cada una de estas piezas como “Beans” de Spring.



Como podemos observar, para definir un bean en Spring se utiliza el tag “bean”, al cual se le asigna un “id” único y la clase que define al bean.

Utilizando el tag “property” se puede inyectar un valor al bean. El atributo “name” es el nombre del atributo de la clase que tiene definido un método set en el bean, y el atributo “value”, es el valor que se le inyectara a este bean a través del método set.

Ahora, nuestra clase Test es mucho más simple:



Hasta aquí todo bien, pero.....……que sucedería si tuviéramos que definir 60 beans que representen a algunos objetos del dominio de nuestra aplicación, los que a su vez dependen de 15 objetos de servicios o cualquier otra cosa. Lo único que conseguiríamos sería un gran archivo XML con muchas definiciones de beans.

Una solución sería dividir este XML, en XMLs más pequeños, pero igual seguiríamos con el problema de que en la medida que se necesiten nuevos bean se seguirán definiendo nuevos archivos XML.

Con la versión de Spring 2.5 tenemos una mejor opción, el uso de anotaciones!!. En esta versión, Spring provee un conjunto de anotaciones que resuelven la dependencia de los objetos sin tener que utilizar XML.

Veamos un ejemplo de esto:

















La anotación "@ Autowired" le informa a Spring, que deberá inyectar automáticamente la dependencia, basado en el tipo definido como Autowired (para nuestro caso, las piezas del robot).

Spring también nos permite definir que objeto será inyectado basándose no solamente en su tipo, sino también utilizando el nombre del bean, a través de la anotación "@ Qualifier".

Pero como le definimos un nombre a los beans? Utilizando la anotación "@Component". Con esta anotación, registramos un nuevo bean que se encuentra disponible para ser inyectado por el contenedor de Spring.

Con estas anotaciones, ya no es necesario definir los "Beans" en un XML.

Ahora, solamente nos queda decirle a Spring, que los bean se encuentran definidos utilizando anotaciones, para lo cual nuestro XML de configuración se reduce a esto:



Para nuestro test utilizaremos JUnit integrado a Spring:



Con este simple ejemplo ya podemos ver algunos de los conceptos básicos de Spring.

En el próximo post veremos las diversas opciones de configuración de los Beans utilizando XML y algunos conceptos básicos del “Core” como el "BeanFactory".

Si alguien quiere mas información sobre el paquete “JDBC”, José Miguel Selman está desarrollando una excelente serie de artículos introductorios que pueden encontrar aquí.