Spring MVC y Spring Security

En este post voy a explicar cómo proteger una aplicación Spring MVC utilizando el módulo Spring Security. Se trata de una guía muy ràpida y para nada seria. Se parte de la base de que tenemos un proyecto web Maven recien generado

Dependencias a añadir al fichero pom.xml de Maven.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
            <version>2.5.6.SEC01</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>2.5.6.SEC01</version>
        </dependency>
        <dependency>
            <groupId>commons-lang</groupId>
            <artifactId>commons-lang</artifactId>
            <version>2.4</version>
        </dependency>
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.security</groupId>
            <artifactId>spring-security-core</artifactId>
            <version>2.0.5.RELEASE</version>
            <type>jar</type>
            <scope>compile</scope>
        </dependency>

Modificaciones de /WEB-INF/web.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

 
    <!-- Listener que inicializa el contexto de Spring -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <!-- Ubicación del fichero de configuración de Spring -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/applicationContext.xml</param-value>
    </context-param>
    <!-- Dispatcher Servlet -->
    <servlet>
        <servlet-name>springapp</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>springapp</servlet-name>
        <url-pattern>*.htm</url-pattern>
    </servlet-mapping>
    <!-- Filtro de Spring Security que intercepta las llamadas a las URL de
         la aplicación -->
    <filter>
        <filter-name>springSecurityFilterChain</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>springSecurityFilterChain</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Contenido de /WEB-INF/applicationContext.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:security="http://www.springframework.org/schema/security"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans 
        http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://www.springframework.org/schema/context 
        http://www.springframework.org/schema/context/spring-context-2.5.xsd
        http://www.springframework.org/schema/security
        http://www.springframework.org/schema/security/spring-security-2.0.4.xsd">
 
    <!-- Configuración del acceso a las diferentes URL de la aplicación en función del
         rol del usuario. En este caso toda la aplicación está protegida y se requiere
         de un usuario con rol ROLE_USER para acceder -->
    <security:http auto-config="true">
        <security:intercept-url pattern="/**" access="ROLE_USER" />
    </security:http>
 
    <!-- Algunos usuarios de prueba. Posteriormente podremos cambiar el servicio para
         que vaya a buscar la información de los usuarios a otro lugar (BBDD) -->
    <security:authentication-provider>
        <security:user-service>
            <security:user name="admin" password="admin" authorities="ROLE_USER, ROLE_ADMIN" />
            <security:user name="user1" password="user1" authorities="ROLE_USER" />
            <security:user name="user1" password="user1" authorities="ROLE_USER" />
        </security:user-service>
    </security:authentication-provider>
 
</beans>

Una vez hecho esto, al acceder a cualquier recurso de la aplicación se nos mostrará la pantalla de login por defecto de Spring Security. Otro día veremos cómo personalizar esta página de login. Os dejo con una captura de la página:

Un saludo

Pair Programming

¿Por qué no se practica pair-programming (programación por parejas) en las empresas?

Las ventajas, pensándolo detenidamente 5 minutos saltan a la vista:

• Cuatro ojos ven más que dos. Esto es evidente. El código generado es de mucha más calidad.
• El hecho de que alguien supervise directamente nuestro trabajo (nuestra pareja de programación) influye en que nos esforcemos más.
• Dos personas comparten la responsabilidad de una tarea. El stress es menor.
• Mejora las relaciones de equipo.
• Amplifica la transmisión del conocimiento.

La excusa para no utilizarla que siempre he escuchado es la misma:

“¿Cómo voy a tener a dos personas haciendo una tarea cuando podría hacerla una única persona?”.

Normalmente esta gente suele ser la misma que ve a los programadores, no como una persona o un profesional, sino como un gasto en la cuenta de su proyecto y mi consejo: alejate de esta gente como de la peste

Control de versiones con Git

Últimamente ando bastante engorilado con Git, por lo que este post pretende ser una introducción muy rápida de las cuatro cosillas que estoy aprendiendo sobre este VCS estos días. En siguientes entradas, o lo que es lo mismo sólo $DEITY sabe cuando, muy probablemente escribiré como montar un repositorio Git utilizando el servicio gratuito ofrecido por github.com.

En primer lugar indicar que Git es un sistema distribuido, a diferencia de por ejemplo Subversion o CVS que son centralizados. Esto para nosotros qué quiere decir? Básicamente que no trabajamos con una copia local del código fuente sino con una copia local o clon del repositorio original, más conocido como “master”.
Las ventajas más importante de trabajar de esta forma, siempre bajo mi punto de vista, son que disponemos de todas las utilidades propias del VCS sin ni siquiera tener que estar conectado a una red. Muy útil para acceder al historico de modificaciones de un fichero, comparar versiones, hacer un commit o cualquier cosa que hagas normalmente con tu VCS desde un sitio donde no dispongas de conexión.

Git define también 5 tipos de objetos alguno de los cuales nos serán familiares si hemos trabajado con un VCS antes:

• Blob: El contenido de un fichero gestionado por Git e identificable por el Hash SHA1 que se obtiene del dicho contenido.
• Tree: La estructura del repositorio en un momento determinado (normalmente un commit). Un objeto de tipo Tree tiene N objetos de tipo Blob asociados.
• Commit: Una “foto” del repositorio una vez se han introducido una serie de cambios. Un objeto de tipo commit tiene 1 objeto de tipo Tree asociado.
• Tag: Una etiqueta, normalmente sirve para marcar objetos de tipo commit.
• Índice: Imagen de los cambios que se aplicarán al repositorio en el siguiente commit. En Git, por defecto sólo aplican aquellos cambios que se encuentran reflejados en este índice (están STAGED).

Git a diferencia que otros VCS como Subversion no almacena únicamente los cambios de un fichero sino que almacena el contenido completo de cada revisión. Esto sumado a la forma de trabajar que tiene con los objetos que indiqué antes hacen que en general el funcionamiento de Git sea muy ágil y, bajo mi punto de vista, mucho menos susceptible a error (piensa que cada vez que le pides una revisión en concreto, Git no debe “montarla” sólo “localizarla”).

Sólo por estas cosillas, ya comienzo a estar tentado de cambiar. ¿Habeis trabajado con Git o similar? ¿Qué os parece? ¿Cambiaríais vuestro Subversion/CVS?

Por cierto el libro que estoy leyendo es “Version Control with Git” de la editorial O’Reilly Media por si alguien quiere echarle una leída.

My top recomentations for new programmers

Unsorted list:

• If you use a versioning control system, spend some time learning its basic usage (checkout, checkin, update, diff, merge, …). If you don’t use it, go quickly to get one. Im currently using svn and git.

• Don’t be scared about refactoring your code.

• Write your own documentation. Document your work for your personal profit. While you are documenting and organizing you are thinking in your job by looking it from a different point of view. Think in documentation like in a software-piece, it must be useful and reusable.

• Constantly, try to improve your knowledge about every day tools usage by knowing its internals (keyboard shorcuts or processes) or just learning from your colleages (or Internet users) usage.

• Write automated tests and execute it. You can use continuous integration for doing the job. I like the Hudson CI server.

• Don’t be IDE-dependent for your compilation, use scripts or tools specifically designed for this task. Actually Maven will be my first choice because Java is my main plattform.

• Get feedback about your code. Show them into colleagues or use communities like StackOverflow.

• Learn what KISS and Convention over configuration means. Be aware about overengineering.

• Don’t try to write your own framework or libraries for later use. Learn writing it  if you want, but use well-known community libraries or frameworks. I personally work mainly with Spring Framework and Apache commons.

• Backup your data. Use your own/preferred method. I personally like dropbox.

• Most important. Don’t try to acomplish all of this at same time. Just be patient and

Please, feedback