Listado de palabras en idioma Inglés y Francés

Con el mismo metodo descrito en este post, he obtenido los listados de los idiomas

• Ingles
• Francés

Que sean útiles!!!!

Creando un Realm personalizado para Shiro que permita leer los usuarios de una fuente externa

Como ya hemos vistos en alguno de los post anteriores Apache Shiro es una buena herramienta para las tareas de seguridad mas comunes dentro de una aplicación J2EE. Una de las formas que tiene este framework para permitirnos definir toda la configuración de la seguridad de nuestra aplicación de una manera declarativa y externa a la misma es mediante la creación de un archivo .ini con la siguiente estructura.

[main]
authc.loginUrl = /jsp/login.xhtml
authc.successUrl = /jsp/index.xhtml

[users]
admin=LECTOR
admin=EDITOR

[roles]
LECTOR=nota:leer
EDITOR=nota:crear,modificar

[urls]
/jsp/listaNotas.xhtml=perms["nota:leer"]
/jsp/insertarNota.xhtml=roles["EDITOR"]
/jsp/** = authc


Sin embargo, con frecuencia es posible rellenar de antemano todas las secciones anteriores excepto la de los usuarios. Es muy común que en las aplicaciones de hoy en día obtengamos la información de los usuarios a partir de otro tipo de recursos tales como una Base de Datos LDAP que sin duda nos brindan una mayor flexibilidad para el manejo de los cambios en los mismos (altas y bajas), así como mayor seguridad que un simple archivo de texto. ¿Pero que pasaría si no quisiésemos renunciar a la idea de definir nuestra configuración de seguridad en un archivo .ini pero necesitásemos obtener los usuarios de una fuente externa?

Excavando en la muy bien diseñada arquitectura de Shiro encontramos el concepto de Realm que es una interfaz para dado el nombre y contraseña del usuario actual recuperar la información de autenticación o autorización del mismo, dada que se cuenta con que esta almacenada en un sitio externo. Shiro posee varias clases que implementan esta interfaz para los casos mas comunes tales como :

• AbstractLdapRealm
• ActiveDirectoryRealm
• JdbcRealm
• JndiLdapRealm
• IniRealm. 

Este ultimo es el Realm autorizado en el caso en que usemos un archivo ini. Mirando en el código fuente vemos que su funcionamiento interno consiste en parsear el archivo y extraer cada una de las secciones. Es de esta forma que nos es posible reutilizar esta clase a través de la herencia, pero sustituir en nuestra clase hija el fragmento en el que se cargan los usuarios por nuestra propia forma de obtenerlos. Un ejemplo sería como el que sigue:

...
public class IniConUsuarioExternoRealm extends IniRealm {

private static final String INI_FILE = "/WEB-INF/shiro.ini";

@Override
protected AuthenticationInfo doGetAuthenticationInfo
(AuthenticationToken token) throws AuthenticationException {
actualizarDatosDeUsuario();
return super.doGetAuthenticationInfo(token);
}

@Override
protected void onInit() {
this.setResourcePath("classpath:" + INI_FILE);

super.onInit();
}

public void actualizarDatosDeUsuario
(AuthenticationToken token) {
Map<String, Object> map = FacesContext.getCurrentInstance().
getExternalContext().getSessionMap();

String user = token.getUser();
String pass = token.getPs();
String[] roles = //Aqui obten los roles para tu usuario 
//de donde quiera que los tengas

if (StringUtils.isBlank(user)) {
throw new AuthorizationException("No hay usuarios ni roles");
}

construirCuenta(user, "", roles);
}

private SimpleAccount construirCuenta
(String username, String password, String[] roles) {
SimpleAccount account = getUser(username);
if (account == null) {
account = new SimpleAccount(username, password, getName());
add(account);
}

account.setCredentials(password);

if (roles != null) {
for (int i = 0; i < roles.length; i++) {
String rolename = roles[i];
account.addRole(rolename);

SimpleRole role = getRole(rolename);
if (role != null) {
account.addObjectPermissions(role.getPermissions());
}
}
} else {
account.setRoles(null);
}

return account;
}
}

Utilizando Apache Shiro para la seguridad en una aplicacion Web en Java

Como hemos visto en el post anterior, Apache Shiro es un  framework potente, ligero y fácil de usar que nos permite incorporar aspectos de seguridad a nuestras aplicaciones Java.

Para comenzar a utilizarlo deberás añadir las siguientes dependencias en el pom de tu proyecto.


<dependency>
      <groupId>org.apache.shiro</groupId>
      <artifactId>shiro-core</artifactId>
      <version>1.2.2</version>
</dependency>
<dependency>
<groupId>org.apache.shiro</groupId>
      <artifactId>shiro-web</artifactId>
      <version>1.2.2</version>
</dependency>


Un ServletFilter y un listener deben de ser registrados en el archivo web.xml. Estos serán usado por Shiro para interceptar todas las peticiones http a la aplicación y hacer una verificación de los permisos para el usuario actual. 


<listener>
<listener-class>
        org.apache.shiro.web.env.EnvironmentLoaderListener
</listener-class>
</listener>

 <filter>
    <filter-name>ShiroFilter</filter-name>
    <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>ShiroFilter</filter-name>
    <url-pattern>/jsp/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>INCLUDE</dispatcher>
    <dispatcher>ERROR</dispatcher>
</filter-mapping>

Aunque Shiro nos ofrece diversas formas de definir nuestras reglas de auntentificación y autorización, en este ejemplo utilizaremos un archivo .ini. Esta variante es muy flexible pues como ya se ha dicho, permite declarar las reglas en un archivo externo a la aplicación, de una forma declarativa, haciendo que su modificación futura pueda ser realizada incluso sin realizar una recompilación.

En el archivo .ini. definiremos los usuarios, roles y permisos. También podremos controlar el acceso a cada una de las URL que referencien a páginas de nuestra aplicación, ya sea mediante roles o permisos que tambien pueden ser declarados aquí. Deberá de estar ubicado en algún lugar dentro del classpath de nuestra aplicación

A continuación veremos un definición de cada una de las secciones del mismo

[main]Configuración de los aspectos principales. 
Por ejemplo: La URL por defecto para las peticiones no autorizadas 
y la pagina a navegar por defecto.
authc.loginUrl = /jsp/login.xhtml
authc.successUrl = /jsp/index.xhtml

[users]-->Sección usada para asignar roles a los usuarios
admin=LECTOR
admin=EDITOR

[roles]----> Seccion para asignar permisos a los roles
LECTOR=nota:leer
EDITOR=nota:crear,modificar

[urls]----> Aqui se definen los permisos de cada URL de acuerdo a roles
que tenga el usuario actual, o a permisos que tengan uno de estos roles,
entre muchas otras posibilidades
/jsp/listaNotas.xhtml=perms["nota:leer"]
/jsp/insertarNota.xhtml=roles["EDITOR"]
/jsp/** = authc

Aunque la mayoría de los casos posibles de autorización quedan cubiertos en el archivo ini, algunas veces es necesario ir un poco mas lejos y restringir el acceso solo a determinados componentes dentro de una pagina y no a esta como un todo. Para conseguir esto Shiro posee la clase Subject que brinda detalles sobre el usuario actual y sus permisos a traves de métodos tales como isPermitted(String permiso) o isUserInRole(String role).

Armado con este pequeño mini tutorial es posible configurar nuestra primera aplicación para comenzar a usar el framework Apache Shiro. En proximas entradas contare como beneficiarse de su condición de framework open source y modificar su funcionalidad adaptandola a posibles situaciones, a traves de los multiples puntos de extension que posee.

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.

Solución del problema de los Lucky Tickets

Entre muchas aficiones que tengo, una de ellas es resolver problemas de algoritmia. Soy usuario activo de jurados en línea que no son mas que sitios con bancos de problemas en los cuales el usuario puede registrarse y enviar sus soluciones para que un evaluador automático las califique y de esa forma poder competir con programadores de todo el mundo.

A pesar de haber resuelto mucho ejercicios de este tipo, a menudo me encuentro con que a pesar de haber pasado mucho tiempo pensando en una solución y finalmente de haberla encontrado, al poco tiempo no la recuerdo. Es por esto que me he propuesto la meta de publicar aquí cada solución que envié con una breve explicación de manera que el algoritmo quede descrito para el futuro.

En esta ocasión he resuelto el problema de los Lucky Tickets en lenguaje C#.

using System;
using System.Collections;

class Program
    {
        static void Main(string[] args)
        {
            int x = int.Parse(Console.ReadLine());
            Ticket(x);
         }
        public static void Ticket(int cifras)
        {
            int mitad = cifras / 2;
            int result = 0;
         
            for (int i = 0; i <= 9 * mitad; i++)
            {
                int sum=SumanK(i,mitad);
                result += sum * sum;
            }
            Console.WriteLine(result);
        }

        private static int SumanK(int k, int cifras)
        {
            if (cifras == 1 && k<10)
            {
                return 1;
            }
            int min = Math.Min(k, 9);
            int max = Math.Max(0, k - 9 * (cifras - 1));
            int count = 0;

            for (int i = max; i <= min; i++)
            {
                count=count+SumanK(k - i, cifras - 1);  
            }
            return count;
        }     
    }
Solución:
La solución puede dividirse en 2 partes muy simples. La primera es detectar cuantas distintas sumas existen donde los sumandos sean los dígitos de números de n/2 cifras. De esta forma para por ejemplo n=6, n/2=3--> 9*9*9=27. Las posibles sumas de los dígitos de números de 3 dígitos vas desde 0 hasta 27.

Dicho, esto solo tendríamos que encontrar para cada uno de estos valores de posible suma, que combinaciones de digitos hacen que se pueda obtener la misma. Para esto se usa el algoritmo recursivo implementado mediante la función SumanK, que funciona de esta forma:

Dadas la cantidad de cifras c y el numero a obtener como suma k:

• Si c=1 y k<10 se devuelve 1
• Si c>1 
• El mínimo dígito posible para la ultima posición sería el Máximo entre 0 y k-9*Todos los dígitos restantes
• El máximo dígito posible sería el mínimo entre k y 9
• Iterando desde mínimo hasta máximo (valor i) y se calcula recursivamente cuantos números suman k-i y tienen una cifra menos.

Creando un UserType de hibernate que se aplique a todas las entidades.

Hibernate posee un mecanismo muy potente para controlar la manera en que ocurre la conversion de valores obtenidos de la fuente de datos a valores Java. Se trata de los UserTypes. Por ejemplo, si utilizas una Base de Datos muy antigua que mantiene siempre al final de cada cadena espacios en blanco hasta rellenar la longitud de la columna, mediante un UserType puedes redefinir la manera en que la cadena es leida de la base de datos y escrita en el String de destino de Java. Para manipular dicho proceso basta con implementar una clase heredera que redefina algunos métodos y dejar que el framework realice el resto

package es.hib.usertype;

import java.io.Serializable;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Types;

import org.hibernate.HibernateException;
import org.hibernate.engine.spi.SessionImplementor;
import org.hibernate.usertype.UserType;

public class TrimmedString implements UserType {

public TrimmedString() {
super();
}

@Override
public int[] sqlTypes() {
return new int[] { Types.VARCHAR };
}

@Override
public Class returnedClass() {
return String.class;
}

@Override
public boolean equals(Object x, Object y) throws HibernateException {
return (x == y) || (x != null && y != null && (x.equals(y)));
}

@Override
public Object deepCopy(Object value) throws HibernateException {
if (value == null)
return null;
return new String((String) value);
}

@Override
public boolean isMutable() {
return false;
}

@Override
public Object assemble(Serializable cached, Object owner) throws
 HibernateException {
return cached;
}

@Override
public Serializable disassemble(Object obje) throws 
HibernateException {
return (Serializable) obje;
}

@Override
public int hashCode(Object obje) throws HibernateException {
return obje.hashCode();
}

@Override
public Object nullSafeGet(ResultSet rs, String[] names, 
SessionImplementor arg2, Object owner) throws HibernateException,
SQLException {

String val = rs.getString(names[0]);

if (null == val) {

return (null);
}
return val.trim();
}

@Override
public void nullSafeSet(PreparedStatement st, Object value, 
int index, SessionImplementor arg3) throws HibernateException,
SQLException {
st.setString(index, (String) value);
}

@Override
public Object replace(Object original, Object target, Object owner) 
throws HibernateException {

return original;
}
}

Ya teniendo el UserType implementado puede decidirse si usarse localmente

@Type(type="es.hib.usertype.TrimmedString")
@Column(name = "DESCRIPCION")
private String descripcion;

o globalmente, o sea, aplicarlo a la conversion de todos los VARCHAR en String de la aplicación. Para esto se debe crear en el paquete que contiene las entidades el siguiente archivo package-info.java. El mismo es una anotación a nivel de paquetes que surtirá el mismo efecto que si se anotaran una a una todas las clases del paquete dado.

@org.hibernate.annotations.TypeDef(name = "trimmedString", 
defaultForType = String.class, typeClass = TrimmedString.class)
package es.hib.entities;

import es.hib.usertype.TrimmedString;

Después de creado el package-info.java, ya solo se necesita que hibernate lo note. Para esto debe de agregarse,  programaticamente cuando se esten cargando las configuraciones añadir la siguiente sentencia.

configuration.addPackage("es.hib.entities")