Introducción a Apache Shiro

Apache Shiro es un framework escrito en el lenguaje Java pensado para ser usado en las tareas mas comunes relacionadas con la seguridad. Estas vendrían a ser Autenticación, Autorización, Encriptación y manejo de sesiones. Es un proyecto bastante maduro y estable y fue aceptado por la Apache Software Foundation en 2008 y ha sido un proyecto de primer nivel dentro de dicha fundación desde 2010.

Las características mas valorables que posee Shiro que lo hacen ser mas popular que los frameworks con los que compite en el panorama de seguridad (por ejemplo JAAS) para aplicaciones Java son:

• Es simple y fácil de usar.
• Fue concebido pensando en ser usado en aplicaciones Webs desde el inicio (JAAS por ejemplo comprende áreas tan especificas como la seguridad a nivel de maquina virtual lo que lo hacen mucho mas complejo )
• Casi todos los aspectos de seguridad pueden ser definidos de manera declarativa en un archivo externo haciéndolo modificable incluso en aplicaciones desplegadas. Cuando la autorización se realiza programaticamente es basada en anotaciones en POJOS lo que hace que se necesite menos código de configuración
• Las posibilidades que ofrece para declarar los aspectos de la autorización son muy especificas y flexibles a la vez. Permite Autorización basada en roles y permisos.
• Brinda una capa de Manejo de Sesiones propia, solapando la que pudiese tener el contenedor de la aplicación. De igual forma Shiro soporta la clusterización de sesiones, de manera que si la sesión fuese propagada entre clusteres, la persistencia de los datos de sesión es manejada por el framework.

Hasta aquí esta corta introducción a Shiro. En un próximo post explicaré como comenzar a utilizarlo en un proyecto desde cero.

Usando Hibernate para acceder a DB2. Lecciones aprendidas

A la hora de desarrollar una aplicación Java con Hibernate y que acceda a una base de datos DB2 se deben tener en cuenta ciertas características de esta Base de Datos que la hacen especial y pueden ocasionar ciertos problemas.

1)DB2 siempre añade espacios al final de las cadenas.

Solución:

Se puede crear un UserType de Hibernate que actue como "traductor" entre las cadenas recién extraídas mediante la consulta SQL y el String final que se obtendrá en Java. Mas detalles de este tema pueden ser vistos en el articulo previo.

2)Se obtiene un 

THE STRING REPRESENTATION OF A DATETIME VALUE IS NOT A VALID DATETIME VALUE

DB2 SQL Error: SQLCODE=-181, SQLSTATE=22007, SQLERRMC=null, DRIVER=3.62.56 

cuando se intenta guardar una fecha de tipo java.util.Date

Solución:

Hibernate y su dialecto para DB2 mapean los objetos de tipo java.util.Date como Sql Timestamp. Esto tiene como consecuencia que se produce un desbordamiento al almacenar la fecha en una columna de tipo Date debido a que los Timestamp poseen mayor precision que Date. La solución es indicar de alguna forma en la entidad de Java que no se desea que implicitamente se mapee a Timestamp. Esto puede ser conseguido de varias maneras. 

Una de ellas sería cambiar el tipo de las fechas en la entidad a java.sql.Date, aunque esto implicaría que nuestro modelo de datos fuese dependiente de las fechas del package sql. 

La otra y mas recomendable es añadir @Type(type="date") a la fecha declarada en la entidad. Esto modificaría la conversión por defecto haciendo que en lugar de enviar un Timestamp al Sql se envie un Date.