Acceder a Properties Según el Contexto con Spring y Tomcat

Cuando una aplicación web se instala en diferentes servidores suele ser necesario modificar ciertos parámetros como direcciones de otros servidores (por ejemplo de correo), parámetros de conexión a la base de datos o hasta parámetros internos de la aplicación como cantidad de usuarios admitidos o nivel de log.

En un clarísimo artículo intitulado 6 Tips for Managing Property Files with Spring ese es uno de los temas: tener diferentes valores para ciertas properties según en qué ambiente o contexto está ejecutándose la aplicación. Una de las posibles soluciones es tener varios archivos llamados por ejemplo

  • database-prod.properties
  • database-test.properties
  • database-desa.properties

Cada archivo tendrá las mismas properties con los valores acordes a cada ambiente (producción, desarrollo y testing en el ejemplo). Lo que tenemos que hacer es que se lea el archivo correcto según el ambiente.

La clave es Spring que tiene un mecanismo muy flexible para acceder a properties mediante el PropertyPlaceholderConfigurer o el PropertySourcesPlaceholderConfigurer. Esos beans hacen el trabajo pesado; nosotros sólo tenemos que configurarlos según nuestras necesidades.

Una configuración típica de ese bean es algo así

 <context:property-placeholder
        location="classpath:database.properties"
        system-properties-mode="OVERRIDE"
        ignore-unresolvable="true"/>

Teniendo muchas versiones del archivo database.properties, la configuración quedaría de esta forma

 <context:property-placeholder
        location="classpath:database-${ambiente}.properties"
        system-properties-mode="OVERRIDE"
        ignore-unresolvable="true"/>

La intención es que ${ambiente} se reemplace por “desa”, “test” o “prod”. Para lograrlo hay que hacer estos pasos:

1) Definir en el archivo server.xml del Tomcat una variable de entorno dentro de GlobalNamingResources

  <Environment
            name="ambiente"
            value="desa"
            type="java.lang.String"
            override="false"/>

2) Definir en el elemento Context en el archivo META-INF/context.xml de la aplicación web esta referencia a la variable que creamos en el punto anterior

  <ResourceLink
      global="ambiente"
      name="ambiente"
      type="java.lang.String"/>

De esa forma Spring va a leer el archivo properties según el valor definido en el server.xml.

Anuncios

Conceptos Básicos de Spring Security

Spring Security es el framework de autenticación y control de acceso de Spring.

Autenticación en el caso más usual es determinar que el usuario que accede al sistema es quien dice ser. Spring soporta muchísimas formas de hacer la autenticación y van desde la más básica que es un simple formulario HTML hasta otras como OpenID, CAS, LDAP, Kerberos, JAAS, etc.

Control de acceso es determinar si un usuario puede realizar una determinada acción dentro del sistema. En muchos casos no tiene sentido realizar el control de acceso usuario por usuario sino agrupando a todos los usuarios que pueden realizar las mismas acciones dentro del sistema. Es decir, no se define “María y Roberto pueden imprimir facturas” sino, “todos los usuarios que sean vendedores pueden imprimir facturas”. Si hoy Juan es encargado de limpieza entonces no puede imprimir facturas, pero el día de mañana, Juan podría ser ascendido a área de ventas y ser vendedor, por lo que entonces sí podrá imprimir facturas. La forma de agrupar a “todos los usuarios que sean vendedores” es mediante roles. Entonces en un momento sólo María y Roberto tienen el rol “ROLE_VENDEDOR” y posteriormente se agregará Juan a ese grupo asignándole dicho rol.

Entender que un rol no es otra cosa que un conjunto de usuarios es muy importante.

Spring permite controlar el acceso en tres niveles

  1. URLs de una aplicación WEB,
  2. métodos de un Bean de Spring.
  3. objetos del dominio.

La única diferencia entre las tres es qué operación es la que se está controlando.

En el primer caso, se busca controlar el acceso a un grupo de recursos que son identificables mediante una URL. Por ejemplo si nuestra aplicación web tiene una página que sólo debe ser accedida por un gerente y no por todos los demás empleados, una estrategia sería que la URL de esa página fuera por ejemplo “/gerencia/index.jsp” y se configurara Spring Security para que sólo usuarios con rol “ROLE_GERENTE” pudieran acceder a URLs que empezaran con “/gerencia”.

El segundo caso busca controlar la ejecución de un método en particular. Se usa en situaciones donde no se trata de una aplicación web, cuando no es posible tener URLs distintas para diferenciar el acceso o cuando independientemente de qué URL fue solicitada desde el cliente queremos asegurarnos de que no se ejecute un método si no se trata del usuario que tiene el permiso. Los métodos que pueden ser controlados son métodos de objetos que sean Beans de Spring, no cualquier objeto.

El tercer caso busca controlar el acceso a objetos de dominio. El ejemplo más claro es para extraer dinero de una cuenta bancaria. Se debe verificar que el usuario sea el dueño de esa cuenta en particular y la relación de quién es dueño de qué cuenta puede ir variando en el tiempo por ejemplo a medida que se agregan o quitan titulares. En este caso los objetos que se desean controlar no tienen que ser Beans de Spring, puede ser cualquier objeto.

Para resolver el tercer caso se usa un módulo de Spring Security que se llama Domain Object Security o Spring ACLs.

Con Spring ACLs se define para cada objeto (instancias individuales) del dominio que se necesite controlar una lista de usuarios y roles que pueden accederlo. Como un rol no es otra cosa que un conjunto de usuarios, en verdad lo que se indica para cada objeto del dominio es directa o indirectamente una lista de usuarios.

Gráficamente lo que se tiene es un objeto del dominio, como por ejemplo una cuenta bancaria:

{Cuenta 123541500542}

y asociada al objeto una lista de usuarios que están autorizados a sacar dinero de esa cuenta

{Cuenta 123541500542} -> {“Juan”, “Pedro”, “Susana”}

Cuando la aplicación está por realizar la operación de débito sobre esa cuenta debemos indicarle a SpringSecurity que verifique que el usuario que está realizando la operación esté en la lista de usuarios de la cuenta sobre la que se está operando.

¿Cómo sería esto con la intervención de roles? Supongamos que existiera en el sistema un rol “ROLE_GERENTE_DE_CUENTAS” y que de acuerdo a las reglas del banco un usuario con ese rol está autorizado a realizar débitos sobre cualquier cuenta. La ACL quedaría así

{Cuenta 123541500542} -> {“Juan”, “Pedro”, “Susana”, “ROLE_GERENTE_DE_CUENTAS”}

Spring Security verificará en el momento que le sea indicado si el usuario que está intentando realizar la operación es Juan, Pedro, Susana, o algún usuario que tenga asignado el rol “ROLE_GERENTE_DE_CUENTAS”. Nuevamente,  como un rol no es otra cosa que un conjunto de usuarios en la lista la presencia de un rol es sólo una forma indirecta de referirnos a usuarios.

Si en cambio se define a los roles como un conjunto de “operaciones” o un conjunto de “permisos” es más difícil entender qué hace el rol en la lista de usuarios autorizados y por lo tanto entender cómo adaptar Spring ACLs a nuestra aplicación.

Spring ACLs es muy flexible y potente ya que permite manejar varios permisos como lectura, escritura, borrado y además permite otorgar y revocar permisos. Por ejemplo si le otorgamos permiso al rol “ROLE_GERENTE” y se lo revocamos al usuario “Juan” que  tiene ese rol, lo que logramos es definir que todos los gerentes menos “Juan” tienen otorgado el permiso. También podría ser a la inversa y definiríamos que ningún gerente tenga permiso a excepción de “Juan”. Si vemos los roles  como conjuntos de usuarios, es simplemente quitar elementos del conjunto.

Para aprender más en detalle cómo usar Spring ACLs, se pueden consultar estos dos artículos

Formato de Números y Fechas con Spring Web MVC

import java.math.BigDecimal;
import java.util.Date;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Past;
import javax.validation.constraints.Digits;
import javax.validation.constraints.Max;
import javax.validation.constraints.Min;
import javax.validation.constraints.Size;
import org.springframework.format.annotation.DateTimeFormat;
import org.springframework.format.annotation.NumberFormat;

// ...
    @DateTimeFormat(pattern = "dd/MM/yyyy")
    private Date control;

    @NumberFormat(style = NumberFormat.Style.NUMBER)
    @Digits(integer = 5, fraction = 5)
    private BigDecimal distantVisualAcuity;

    @Max(100)
    @Min(10)
    @NumberFormat(style = NumberFormat.Style.NUMBER)
    private BigDecimal totalInterpupilaryDistance;

    @NotNull
    @Past
    @DateTimeFormat(pattern = "dd/MM/yyyy")
    private Date date;

Spring Web MVC convierte los datos ingresados por el usuario al tipo de dato del Bean que respalda el formulario. No es necesario escribir una sola línea de código para convertir la enorme mayoría de los valores que se ingresan. Basta con usar algunas annotations muy sencillas. En el caso de números se puede establecer, por ejemplo, la cantidad de dígitos enteros y fraccionarios, sin tener que recurrir a una máscara de entrada.

Para poder usar la annotation DateTimeFormat hay que incorporar joda-time como dependencia.

La conversión funciona tanto para el ingreso de texto como para el formateo a la hora de editar el formulario.

Las annotations así usadas son además documentación del sistema. Cualquier persona que vea cómo está anotada la variable sabe el tipo de valores de entrada que admite sin tener que mirar otra cosa.

Por Qué Usar Spring Web MVC Framework

1.- Porque la asignación de qué método se ejecuta cuando se carga una URL se puede hacer con una annotation en forma directa y simple.

@Controller
public class User {
    @RequestMapping("/admin/user")
    public String listUsers(Model model) {
        model.addAttribute("users", this.userService.listAll());
        return "userList";
    }
}

Con sólo usar la annotation  @RequestMapping Spring sabe que cuando se ingrese la URL /admin/user hay que ejecutar el método listUsers de la clase User.

2.- Porque los controllers no son más que un objeto cualquiera que lleva una annotation.
En el ejemplo, la clase User no tiene nada en particular. No implementa ninguna interfaz ni hereda de ninguna clase en particular. Sólo se requiere anotarla con @Controller.

3.- Porque todas las validaciones se pueden hacer con annotations usando Bean Validation (JSR 303).

@ScriptAssert(
    lang = "Groovy",
    script = "_this.password.equals(_this.password2)",
    message="{password.confirm}")
public class UserDTO extends PersonDTO {

    @NotEmpty
    @Size(min=5,max=20)
    private String login;

    @Size(max=40)
    private String password;

    @Size(max=40)
    private String password2;
}

En este ejemplo, la clase UserDTO es el respaldo del formulario de alta de usuarios. En el caso del campo login, se valida que esté presente y que sea de entre 5 y 20 caracteres. El caso de la password, que sea como máximo de 40 y para verificar que coincidan ambas contraseñas ingresadas, se usa la annotation @ScriptAssert que permite realizar validaciones más complejas ejecutando código mediante un lenguaje de scripting (en este caso Groovy) sin tener que recurrir a codificar un validador propio.

Cuando el script fuera muy complejo se puede directamente invocar un método del objeto anotado de esta forma:

@ScriptAssert.List({
    @ScriptAssert(lang = "Groovy",
        script = "_this.checkQuery()",
        message = "{report.enterQuery}"),
    @ScriptAssert(lang = "Groovy",
        script = "_this.checkParameterCount()",
        message = "{report.paramCount}")})
public class ReportDTO extends EntityDTO {

    /* ... resto del código de la clase ... */

 public boolean checkParameterCount() {
        return this.parameters.size() == this.getExpectedParameters();
    }

    public boolean checkQuery() {
        return this.query != -1 || (this.sql != null && this.sql.length() > 10);
    }
}

Así se puede escribir en el mismo objeto que respalda el formulario uno o varios métodos que realicen validaciones y se los invoca desde la annotation usando un lenguaje de scripting directamente. En el ejemplo se ve cómo ejecutar varias validaciones cada una con su propio mensaje de error y su script.

4.- Porque permite manejar distintos tipos de request (GET, POST, PUT, DELETE, HEAD y OPTIONS) en forma individual o todos juntos.


// ...

    @RequestMapping(value = "/admin/report/edit", method = RequestMethod.GET)
    public ModelAndView editReportForm(
            @RequestParam(required = true, value = "id") int id) {
// ...
    @RequestMapping(value = "/admin/report/edit", method = RequestMethod.POST)
    public String editReport(
            @ModelAttribute("reportDto") @Valid ReportDTO report,
            BindingResult result,
            SessionStatus status) {
// ...

En el ejemplo, la misma URL, /admin/report/edit, es manejada por diferentes métodos del controller según que annotation se use. Típicamente en el GET se devolvería el formulario de edición con los datos cargados y en el POST se haría la edición según las modificaciones ingresadas por el usuario.

Proyecto Básico de Ejemplo con Spring 3.0

Este proyecto NetBeans [http://ubuntuone.com/p/GVo/] sirve de ejemplo para configurar una aplicación web usando:

  • Maven
  • Spring 3.0.4
  • Hibernate 3.5
  • SpringSecurity 3.0.3
  • HibernateValidator 4.1.0

Está configurado usando annotations en todo. Los beans de Spring están anotados con @Service y @Repository. Los mapeos de Hibernate están también hechos con annotations, al igual que los controllers de Spring@MVC. Las validaciones en Spring@MVC están hechas con las annotations definidas por Hibernate Validator.