Códice | Entradas sobre «java»

ConsoleInput kit

JavGuerra — Tue, 31 Jan 2023 00:00:00 GMT

Etiquetas: #java, #consola, #código

Cuando se emplea la clase Scanner en Java surgen multitud de inconvenientes a la hora de solicitar datos por consola. Algunos errores están asociados a la introducción de tipos de datos no solicitados, pero hay un problema especialmente incómodo, el de las pulsaciones de tecla Intro que quedan en el buffer del Scanner. En esta entrada muestro cómo solucionar esto con algunos métodos básicos de ejemplo.

Lo primero: abrir y cerrar

Voy a crear una clase de utilidad ConsoleInput que no permite ser instanciada.

Para poder leer por consola, necesitaré usar la clase Scanner dentro de mi clase ConsoleInput, y también crearé un método para poder cerrar el Scanner.

public final class ConsoleInput {

    ...

    private static Scanner IN = new Scanner(System.in);

    public static void closeScanner() {
        if (IN != null && !IN.isClosed()) {
            IN.close();
        }
    }

    private static void ensureScannerOpen() {
        if (IN == null || IN.isClosed()) {
            IN = new Scanner(System.in);
        }
    }

    public static void resetScanner() {
        closeScanner();
        IN = new Scanner(System.in);
    }

    ...
}

Como se aprecia, dentro de un paquete llamado utilities creo la clase ConsoleInput, el objeto IN de tipo Scanner que debe importarse de java.util.Scanner y creo un método que, cuando sea llamado, cerrará el Scanner IN con el método .close().

También he añadido dos métodos más relacionados con cerrar el scanner: ensureScannerOpen() para cerciorarme de que el scanner esté abierto y resetScanner() para cerrarlo y abrir uno nuevo si fuera necesario en nuestra aplicación.

El método ensureScannerOpen() se incluye en cada método que espera datos por consola para evitar problemas si el scanner no está abierto. Si no lo está, lo abre de forma transparente al usuario.

Introducir datos por consola

El problema: .next() vs. .nextLine()

Cuando queremos leer un dato por consola, podemos usar el método .next() o .nextLine(), siendo IN el objeto de la clase Scanner instanciado para leer por teclado.

System.out.println("Introduce una palabra");
String entrada1 = IN.next();
System.out.println(entrada1);

System.out.println("Introduce una frase");
String entrada2 = IN.nextLine();
System.out.println(entrada2);

En entrada1 se guardará el dato introducido hasta encontrar un espacio en blanco. En entrada2 se guardará el dato introducido hasta encontrar Intro, incluidos los espacios en blanco.

Pero hay un problema en este código. Tras escribir la palabra que se solicita y pulsar Intro, se guarda en entrada1 la palabra, pero en el buffer del Scanner queda almacenado el Intro, y este será leído por entrada2 y no nos permitirá escribir la frase solicitada.

No ocurre lo mismo si invertimos el orden, es decir, si primero pedimos la frase con .nexLine() y después la palabra con .next(), ya que .nextLine() lee específicamente el Intro tras introducir la frase y este no queda almacenado en el buffer, pudiendo entonces introducir la palabra solicitada tras la frase.

La solución pasa por poner siempre un .nextLine() tras un .next() para evitar problemas, de esta forma:

System.out.println("Introduce una palabra");
String entrada1 = IN.next();
IN.nextLine(); // Lee el intro del buffer
System.out.println(entrada1);

System.out.println("Introduce una frase");
String entrada2 = IN.nextLine();
System.out.println(entrada2);

Y ahora sí, la frase podrá ser introducida en entrada2 y luego mostrada.

Esta solución aplica también a .nextInt(), .nextLong(), .nextDouble() y otros métodos .next() de entrada de la clase Scanner.

Pulse Intro para continuar

La primera aplicación práctica de esto puede ser el método siguiente:

 public static void getEnter() {  
    ensureScannerOpen(); 
    IN.nextLine();  
}

El método .getEnter() es útil cuando queremos esperar que el usuario pulse la tecla Intro para continuar.

Obtener un número largo, entero, positivo

Ahora quiero leer un número por consola que sea entero, largo (long) y positivo. Emplearé el método .nextLong() para obtener el dato, y lo acompañaré de un .nextLine() como mostré antes.

num = IN.nextLong();  
IN.nextLine();

Como puede que el dato introducido no sea un número largo, envolveré estas sentencias con un try-catch:

try {  
    num = IN.nextLong();  
    IN.nextLine();
    ...  
} catch (InputMismatchException e) {  
    System.out.println("Tipo de dato no reconocido.");  
    IN.nextLine();  
}

La excepción InputMismatchException será la encargada de probar (try) si el tipo de dato introducido fue erróneo y de esta forma se llevarían a cabo las instrucciones del bloque catch.

En el bloque catch también se incluye IN.nextLine() ya que, cuando salta la excepción, la línea IN.nextLine(); debajo del IN.nextLong() no llega a ejecutarse.

Si no se incluye esta línea en el catch y estamos solicitando el dato por consola desde un bucle, como en el código que se ve a continuación, la aplicación entrará en un bucle infinito que mostrará el mensaje "Tipo de dato no reconocido.", ya que con cada nueva petición del dato, leería el Intro del buffer no pudiendo introducir el dato solicitado.

Aquí el código completo del método .getLongIntPos():

public static Long getLongIntPos(String message) {
    ensureScannerOpen(); 
    while(true) {
        System.out.print(message);
        try {
            long num = IN.nextLong();
            IN.nextLine();
            if (num >= 0) return num;
            System.out.println("Valor fuera de rango.");
        } catch (InputMismatchException e) {
            System.out.println("Tipo de dato no reconocido. Ingrese un número entero.");
            IN.nextLine();
        }
    }
}

El bucle while se asegura de que, hasta que no se introduzca un dato válido, se esté solicitando el dato por consola. La condición de salida es si num >= 0, momento en el que la función ejecutará el return con el dato num obtenido.

Por parámetro recibimos el mensaje que dará versatilidad a esta función, y que será mostrado por consola antes de requerir el dato. Esta función se podrá usar de esta forma desde otra parte de nuestra aplicación:

Long numero = getLongIntPos("Introduce un número entero: ");
System.out.println(numero);

Obtener un número largo, entero, positivo por rango

Dado el método anterior, es fácil hacer cambios para que el valor recibido se encuentre entre un rango determinado.

public static Long getLongIntPosByRange(String message, Long min, Long max) {
    ensureScannerOpen();   
    if (min > max) {
        Long temp = min;
        min = max;
        max = temp;
    }  
    while(true) {  
        System.out.print(message);  
        try {  
            long num = IN.nextLong();  
            IN.nextLine();
            if (num >= min && num <= max) return num;  
            System.out.println("Valor fuera de rango.");  
        } catch (InputMismatchException e) {  
            System.out.println("Tipo de dato no reconocido.");  
            IN.nextLine();  
        }  
    }  
}

El método .getLongIntPosByRange() solicita esta vez tres parámetros, el mensaje a mostrar (message), el valor del rango mínimo (min) y el máximo (max).

Para evitar errores y complicar el código, asumo que si el valor máximo es menor que el valor mínimo, es que deben cambiarse, pero esta no sería la mejor forma de hacerlo.

La otra diferencia con .getLongIntPos() es que la condición de salida ahora es que el número que recibimos por consola debe estar entre los valores mínimo y máximo indicados (num >= min && num <= max).

Obtener una palabra

El código del método .getWord() obtiene una palabra.

public static String getWord(String message) {  
    ensureScannerOpen(); 
    while(true) {  
        System.out.print(message);  
        try {  
            String str = IN.next();  
            IN.nextLine();  
            str = str.trim();  
            if (str.length() >= 3) return str;  
            System.out.println("Cadena no válida.");  
        } catch (InputMismatchException e) {  
            System.out.println("Tipo de dato no reconocido.");  
            IN.nextLine();  
        }  
    }  
}

La diferencia con los métodos anteriores es la condición de salida.

Si la palabra introducida no tiene al menos tres caracteres (str.length() >= 3), te la volverá a pedir. A la palabra introducida le limpio los posibles espacios al inicio y final con .trim().

Obtener una cadena de caracteres

En la línea de los casos anteriores, el código del método .getString() obtiene una cadena de caracteres (una frase) sería:

public static String getString(String message) {  
    ensureScannerOpen(); 
    while(true) {  
        System.out.print(message);  
        try {  
            String str = IN.nextLine();  
            str = str.trim();
            if (str.length() >= 3) return str;  
            System.out.println("Cadena no válida.");  
        } catch (InputMismatchException e) {  
            System.out.println("Tipo de dato no reconocido.");  
            IN.nextLine();  
        }  
    }  
}

Aquí no sería necesario poner el IN.nextLine() en el bloque try, y todo lo demás es muy similar. La diferencia es, una vez más, la condición de salida.

Si la cadena introducida no tiene al menos tres caracteres (str.length() >= 3), te la volverá a pedir. A la cadena introducida le limpio los posibles espacios al inicio y final con .trim().

Obtener un Sí o No

Con el método getYesNo() obtengo un true para ‘sí’ o un false para ‘no’. El código es el siguiente:

public static Boolean getYesNo(String message) {  
    ensureScannerOpen(); 
    while(true) {  
        System.out.print(message);  
        try {  
            char chr = IN.next(".").trim().charAt(0);  
            IN.nextLine();  
            if (chr == 'S' || chr == 's') return true;  
            if (chr == 'N' || chr == 'n') return false;  
            System.out.println("Carácter no válido.");  
        } catch (InputMismatchException e) {  
            System.out.println("Tipo de dato no reconocido.");  
            IN.nextLine();   
        }  
    }  
}

Lo destacable de este método es la línea:

chr = IN.next(".").trim().charAt(0);

Que permite que, de los datos introducidos, sólo se almacene un carácter.

En este método vuelve a ser necesario el uso de IN.nextLine().

En muy raras ocasiones, si un usuario presiona Ctrl+D (EOF) en lugar de escribir algo o si se produce corrupción del stream de entrada, se puede recibir un null en chr. Por si acaso, para hacer la clase más robusta, podemos hacer una comprobación para evitarlo:

    String input = IN.next(".");  // ← SEPARADO
    IN.nextLine();  
    
    if (input == null || input.trim().isEmpty()) {  // ← PROTECCIÓN
        System.out.println("Entrada vacía no válida.");
        continue;
    }
    
    char chr = input.trim().charAt(0);

Bonus: limpiar la consola

Buscando por Internet, encontré este sencillo código para limpiar la consola:

public static void clearConsole() {
    for (int i = 0; i < 50; i++) {
        System.out.println();
    }
}

Realmente clearConsole() no limpia la consola. Sólo empuja las líneas hacia arriba. Concretamente, 50 líneas hacia arriba. Esto permite que este simple método funcione en cualquier IDE o sistema operativo, y a efectos prácticos, despeja la consola, que es lo que se persigue.

La clase ConsoleInput completa

El código es el siguiente (cambia el «package» según te interese):

package utilities;  
  
import java.util.InputMismatchException;  
import java.util.Scanner;  
  
/**
 * Clase para leer datos por consola.
 * @author JavGuerra
 * @version 1.1 - 2026-02-13
 * @since 2023-01-31
 * @requires Java 5.0 (1.5) or higher
 * @see <a href="https://javguerra.github.io/blog/clase-scanner-java/">
 *         «ConsoleInput kit» Descripción en el blog del autor.
 *     </a>
 * @see <a href="https://youtu.be/HSq3rRfBmDg">
 *         Video: Entrada de datos en Java - Clase Scanner.
 *         Mega curso Java desde 0, Aula en la nube.
 *     </a>
 */
public final class ConsoleInput {

    /**
     * Constructor privado que evita la instanciación de la clase. 
     */
    private ConsoleInput() {
        throw new AssertionError("No se puede instanciar ConsoleInput");
    }
  
    /** 
     * Instancia de la clase Scanner.
     */
    private static Scanner IN = new Scanner(System.in);  

    /**
     * Cierra el Scanner.
     */
    public static void closeScanner() {
        if (IN != null && !IN.isClosed()) {
            IN.close();
        }
    }

    /**
     * Verifica que el Scanner esté abierto y funcionando.
     * Si está cerrado, lo reabre automáticamente.
     */
    private static void ensureScannerOpen() {
        if (IN == null || IN.isClosed()) {
            IN = new Scanner(System.in);
        }
    }

    /**
     * Reinicia el Scanner (cierra y abre uno nuevo).
     */
    public static void resetScanner() {
        closeScanner();
        IN = new Scanner(System.in);
    }

    /**
     * Espera la pulsación de la tecla Intro.
     */
    public static void getEnter() { 
        ensureScannerOpen(); 
        IN.nextLine();  
    }  
  
    /**
     * Solicita con un mensaje por consola, y comprueba que se introduzca,
     * un número largo, entero, positivo (>=0).
     * @param message String Pregunta del usuario.
     * @return Long Número introducido.
     */
    public static Long getLongIntPos(String message) {
        ensureScannerOpen();  
        while(true) {  
            System.out.print(message);  
            try {  
                long num = IN.nextLong();  
                IN.nextLine();  
                if (num >= 0) return num;  
                System.out.println("Valor fuera de rango.");  
            } catch (InputMismatchException e) {  
                System.out.println("Tipo de dato no reconocido.");  
                IN.nextLine();    
            }  
        }  
    }  
  
    /**
     * Solicita con un mensaje por consola, y comprueba que se introduzca,
     * un número largo, entero, positivo (>=0), cuyo rango esté entre
     * el valor mínimo y el valor máximo recibido, ambos inclusive.
     * @param message String Pregunta del usuario.
     * @param min Long Valor mínimo.
     * @param max Long Valor máximo.
     * @return Long Número introducido.
     */
    public static Long getLongIntPosByRange(String message, Long min, Long max) {
        ensureScannerOpen();  
        if (min > max) {
            Long temp = min;
            min = max;
            max = temp;
        } 
        while(true) {  
            System.out.print(message);  
            try {  
                long num = IN.nextLong();  
                IN.nextLine();  
                if (num >= min && num <= max) return num;  
                System.out.println("Valor fuera de rango.");  
            } catch (InputMismatchException e) {  
                System.out.println("Tipo de dato no reconocido.");  
                IN.nextLine();  
            }  
        }  
    }  

    /**
     * Solicita con un mensaje por consola, y comprueba que se introduzca,
     * una palabra de, al menos, 3 caracteres.
     * @param message String Pregunta del usuario.
     * @return String Palabra introducida.
     */
    public static String getWord(String message) { 
        ensureScannerOpen(); 
        while(true) {  
            System.out.print(message);  
            try {  
                String str = IN.next();  
                IN.nextLine();  
                str = str.trim();  
                if (str.length() >= 3) return str;  
                System.out.println("Cadena no válida."); 
            } catch (InputMismatchException e) {  
                System.out.println("Tipo de dato no reconocido.");  
                IN.nextLine();   
            }   
        }  
    }

    /**
     * Solicita con un mensaje por consola, y comprueba que se introduzca,
     * una cadena de texto de, al menos, 3 caracteres.
     * @param message String Pregunta del usuario.
     * @return String Cadena de texto introducida.
     */
    public static String getString(String message) {
        ensureScannerOpen();  
        while(true) {  
            System.out.print(message);  
            try {  
                String str = IN.nextLine();  
                str = str.trim();  
                if (str.length() >= 3) return str;  
                System.out.println("Cadena no válida.");  
            } catch (InputMismatchException e) {  
                System.out.println("Tipo de dato no reconocido.");  
                IN.nextLine();   
            }  
        }  
    }  
  
    /**
     * Solicita con un mensaje por consola, y comprueba que se introduzca,
     * un carácter para confirmar ('S', 's') o ('N', 'n').
     * @param message String Pregunta del usuario.
     * @return Boolean true/Sí o false/No.
     */
    public static Boolean getYesNo(String message) {
        ensureScannerOpen();  
        while(true) {  
            System.out.print(message);  
            try {  
                String input = IN.next(".");
                if (input == null || input.trim().isEmpty()) {
                    System.out.println("Entrada vacía no válida.");
                    continue;
                }
                IN.nextLine();  
                char chr = input.trim().charAt(0); 
                if (chr == 'S' || chr == 's') return true;  
                if (chr == 'N' || chr == 'n') return false;  
                System.out.println("Carácter no válido."); 
            } catch (InputMismatchException e) {  
                System.out.println("Tipo de dato no reconocido.");  
                IN.nextLine();   
            }   
        }  
    }  
  
    /**
     * Limpia la consola (desplaza el contenido hacia arriba).
     * Funciona en TODOS los sistemas e IDEs.
     */
    public static void clearConsole() {
        for (int i = 0; i < 50; i++) {
            System.out.println();
        }
    } 
  
}

Esta clase puede crecer con nuevos métodos para otros tipos numericos como int o double… que tú mismo puedes hacer.

Puntos fuertes de esta clase

No instanciable - Constructor privado + final class.
Auto-reparable - Scanner se reabre solo.
Robusta - Maneja entradas incorrectas sin caer.
Null-safe - getYesNo() protegido.
Consistente - Todos los métodos usan ensureScannerOpen().
Compatible - Funciona desde Java 1.5.
Documentada - JavaDoc completo.

Un ejemplo de uso

Para finalizar, veamos un caso práctico para la gestión de clientes.

    private static void selectOptions() {
        long totalOpts = 6L;
        String optMsg = "Seleccione una opción (0-6): ";
        String menuList = """
        -------------------
           CRUD Customer
        -------------------
        1. Listar clientes
        2. Mostrar un cliente
        3. Crear un nuevo cliente
        4. Actualizar un cliente
        5. Eliminar un cliente
        6. Eliminar los clientes
        0. Salir
        """;
        byte opt;

        while (true) {
            clearConsole();

            System.out.println(menuList);
            opt = getLongIntPosByRange(optMsg, 0L, totalOpts).byteValue();

            if (opt == 0) break;

            switch (opt) {
                case 1 -> controller.listCustomers();
                case 2 -> controller.listCustomerById();
                case 3 -> controller.newCustomer();
                case 4 -> controller.updateCustomerById();
                case 5 -> controller.deleteCustomerById();
                case 6 -> controller.deleteAllCustomers();
            }

            System.out.println("Pulse <Intro> para continuar.");
            getEnter();
        }

        closeScanner();
    }

Enlaces

Video: Entrada de datos en Java - Clase Scanner - Mega curso Java desde 0, Aula en la nube

Notificaciones con Thymeleaft

JavGuerra — Wed, 03 Jul 2024 00:00:00 GMT

Etiquetas: #código, #java, #spring boot, #bootstrap, #thymeleaft

Cuando una aplicación realiza operaciones potencialmente críticas como editar, guardar o borrar datos de una base de datos, es conveniente notificar al usuario el éxito o fracaso de las operaciones. Esta entrada presenta una solución básica de cómo mostrar notificaciones en la plantilla Thymeleaft.

Se asume que el lector tiene conocimientos generales de Spring Boot, Thymeleaft y Bootstrap para aplicar el contenido.

Planteamiento

La idea es destinar una área de la visualización en la aplicación para las notificaciones, y activar este área sólo cuando se deban mostrar, dando opción al usuario a cerrarlas una vez leídas. Este área puede crearse como un fragmento (th:fragment) e incluirse en las plantillas en las que se requiera, o en todas las plantillas asociadas a las vistas de la aplicación.

Será necesaria una variable que sirva de «llave» para mostrar estas notificaciones o no, y otra para indicar el tipo de mensaje (info, danger…). Como enviar el mensaje desde cada método de erutado de nuestros controladores es algo trabajoso, lo adecuado es usar un filtro de sesión http que me permitirá crear las variables donde guardaré el contenido del mensaje y el tipo de mensaje a mostrar.

Por último, gestionaré el borrado del contenido de la notificación para que esta deje de mostrarse al cambiar de página Para ello necesitaremos otra variable que indique si la notificación ya se ha mostrado.

Programando notificaciones

Para crear las notificaciones, necesitaremos:

Crear un fragmento que servirá para incluir el texto de la notificación en nuestras vistas.
Inicializar las variables de sesión que contendrán la notificación y el tipo de notificación.
Actualizar el valor de las variables de notificación para que estas se muestren.
Eliminar la notificación al cambiar de página.

El fragmento

He creado un fragmento de código llamado messageAlert.html que he incluido en mi carpeta fragments dentro de templates en resources. Este es un ejemplo que puede modificarse a voluntad para adaptar su diseño a la aplicación donde se usará.

<div th:fragment="messageAlert" th:if="${session.message != ''}" class="container">

    <div class="alert alert-dismissible fade show" role="alert"
        th:classappend="${session.messageType} == 'danger'? 'alert-danger' : 'alert-info'">

        <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" width="24" height="24">
            <path stroke-linecap="round" stroke-linejoin="round" d="M14.857 17.082a23.848 23.848 0 0 0 5.454-1.31A8.967 8.967 0 0 1 18 9.75V9A6 6 0 0 0 6 9v.75a8.967 8.967 0 0 1-2.312 6.022c1.733.64 3.56 1.085 5.455 1.31m5.714 0a24.255 24.255 0 0 1-5.714 0m5.714 0a3 3 0 1 1-5.714 0M3.124 7.5A8.969 8.969 0 0 1 5.292 3m13.416 0a8.969 8.969 0 0 1 2.168 4.5" />
        </svg>&nbsp;&nbsp;

        <span class="align-middle" th:text="${session.message}"></span>

        <button class="btn-close" data-bs-dismiss="alert" aria-label="Cerrar"></button>
    </div>
</div>

Con th:if="${session.message != ''}"determino si este fragmento se mostrará o no. Si el valor de la variable de sesión llamada message está vacío, es que no hay nada que mostrar, de otra forma, el fragmento se mostrará.

Con th:classappend="${session.messageType} == 'danger'? 'alert-danger' : 'alert-info'" determino qué tipo de alerta de Boostrap mostrar, si una destinada a informar (recuadro con fondo azul) o una destinada a alertar de un fallo (recuadro con fondo rojo). Esto lo consigo mediante la variable de sesión messageType.

Tras el icono SVG que se mostrará en el aviso, se incluye el mensaje de la notificación con th:text="${session.message}" dentro de la etiqueta span.

Con el button, ayudado por Bootstrap, el usuario puede cerrar la notificación.

Para incluir este fragmento en la vista donde deseo que se muestre la notificación, uso:

<div th:replace="~{fragments/messageAlert :: messageAlert}"></div>

Inicializando las variables message y messageType

Como he comentado, voy a usar variables de sesión http para guardar el contenido del mensaje y el tipo de mensaje. Para ello creo un filtro de sesión que compruebe, por cada petición http, si existe una sesión y si las variables de sesión están creadas.

He incluido el siguiente componente en /Utils/SessionFilter.java:

@Component
public class SessionFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {}

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        HttpSession session = httpRequest.getSession(true);

        if (session!= null) {

            // Variables para las notificaciones

            if (session.getAttribute("message") == null)
                session.setAttribute("message", "");

            if (session.getAttribute("messageType") == null)
                session.setAttribute("messageType", ""); 
                // Valores: "danger" u otro cualquiera = "info".

        }

        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {}
}

Con HttpSession session = httpRequest.getSession(true); Obtengo la sesión, y si no existe, se creará una nueva. Esto ocurre porque he incluido el valor true en .getSession(true).

Si existe la sesión (que, salvo error, ya debería existir), compruebo que las variables message y messageType estén inicializadas, y si no lo están las inicializo a "".

Tras esto, ya podremos usar session.getAttribute() y session.setAttribute() para leer y para actualizar el valor de las variables de sesión desde nuestros servicios o controladores, como veremos.

Usando mensajes

Pensemos en un servicio que guarde el contenido de un formulario para crear un cine. Sería algo similar a esto:

@Slf4j
@RequiredArgsConstructor
@Service
public class CinemaServiceImpl implements ICinemaService {

    private final CinemaRepository cinemaRepo;

    // Otras propiedades y métodos de la clase aquí

    @Override
    @Transactional
    public Cinema save(Cinema cinema) {
        log.info("save {}", cinema);

        try {
            return cinemaRepo.save(cinema);

        } catch (Exception e) {
            log.error("Error al guardar el cine: ", e);

            return null;
        }
    }
}

Como se ve, la clase CinemaServiceImpl implementa la interfaz ICinemaService, inyecta el repositorio CinemaRepository y tiene un método que guarda un cine. cinema es enviado al método save desde el controlador que lo usa, y el método devuelve el cine guardado o null si se produjo un error.

A continuación muestro cómo se verá el método al incluir los mensajes de éxito o error:

@Slf4j
@RequiredArgsConstructor
@Service
public class CinemaServiceImpl implements ICinemaService {

    private final HttpSession session;
    private final CinemaRepository cinemaRepo;

    // Otras propiedades y métodos de la clase aquí

    @Override
    @Transactional
    public Cinema save(Cinema cinema) {
        log.info("save {}", cinema);

        try {
            Cinema newCinema = cinemaRepo.save(cinema);

            String message = "Cine " + newCinema + " guardado.";

            session.setAttribute("message", message);
            session.setAttribute("messageType", "info");

            return newCinema;

        } catch (Exception e) {
            log.error("Error al guardar el cine: ", e);

            session.setAttribute("message", "El cine no ha podido guardarse.");
            session.setAttribute("messageType", "danger");

            return null;
        }
    }
}

Con session.setAttribute("message", message); se cambia el valor de la variable message, y con session.setAttribute("messageType", "info"); se hace lo propio con la variable messageType. Lo mismo ocurre en caso de error.

A tener en cuenta: en String message = "Cine " + newCinema + " guardado correctamente."; hay que estar seguro de que la entidad Cinema sobrescribe (@Override) el método toString() para poder usarlo como String.

El resultado es algo como lo que se muestra a continuación.

Lo que se ve es lo que hemos definido en el fragmento messageAlert.html que hemos incluido en la plantilla de la vista.

Mensajes encadenados

Si realizamos más de una gestión crítica desde un mismo controlador, como, por ejemplo, actualizar la información de un cine, y si este no está está operativo (p.ej. si ha cerrado temporalmente), entonces desactivar todas las salas de ese cine para que no se muestren en la aplicación, podemos encadenar los mensajes de ambos servicios. Para ello debemos leer el valor de la variable message en el segundo servicio, el que se ocupe de desactivar las salas, y añadir el aviso al nuevo mensaje, ya que sólo disponemos de un mensaje que puede ser mostrado a la vez:

String message = (String) session.getAttribute("message");
session.setAttribute("message", message + " Salas desactivadas correctamente.");

Cerrando la notificación al cambiar de página

Como sabemos, la notificación puede cerrarse haciendo clic en la X de cierre, o bien cerrarse cuando cambiamos de página. Al cambiar de página, el filtro SessionFilter se ejecutará, y para que ocurra lo que queremos es necesario incluir una nueva variable y mas comprobaciones, como se muestra a continuación:

@Component
public class SessionFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {}

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        HttpSession session = httpRequest.getSession(true);

        if (session!= null) {

            // Variables para las notificaciones

            if (session.getAttribute("message") == null)
                session.setAttribute("message", "");

            if (session.getAttribute("messageType") == null)
                session.setAttribute("messageType", ""); 
                // Valores: "danger" u otro cualquiera = "info".

            // Cierre de notificaciones al cambiar de página

            if (session.getAttribute("messageActivated") == null)
                session.setAttribute("messageActivated", false);

            if ((boolean) session.getAttribute("messageActivated")) {
                session.setAttribute("message", "");
                session.setAttribute("messageActivated", false);
            }

            if (!Objects.equals((String) session.getAttribute("message"), ""))
                session.setAttribute("messageActivated", true);
            
        }

        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {}
}

En estos tres nuevos bloques de sentencias if , primero compruebo que la variable de sesión messageActivated está inicializada, como hacía con las otras variables de sesión, y si no lo está, la inicializo a false.

Como cada vez que se muestra una página en la aplicación se lanza SessionFilter, en el siguiente bloque de sentencias compruebo si messageActivated está activado (true), y si lo está, la desactivo, y vacío message para que no vuelva a mostrarse la notificación. Recordemos que el fragment messageAlert.html sólo muestra la notificación si su contenido no es "".

En el último bloque, si message contiene texto y es la primera vez que se va a mostrar la notificación, el bloque anterior no la habrá borrado. Entonces activo messageActivated para que la notificación pueda ser eliminada la siguiente vez que se muestre una página.

Como se aprecia, messageActivated actúa como indicador de borrado, y en este proceso es determinante el orden en el que se hacen las comprobaciones.

Con esto, ya tenemos activo nuestro propio sistema de notificaciones para Thymeleaft.

Adaptando este método sería posible, por ejemplo, generar notificaciones que permitan consultar al usuario si quiere llevar a cabo o no una tarea determinada, como p.ej. "¿Desea borrar el cine? [Sí] [No]".

BONUS: Aviso de cookies

Es fácil realizar los cambios para, por ejemplo, notificar un aviso de cookies con un botón de aceptar que permanezca abierto hasta que el usuario lo cierre, o incluso poner un banner, o cualquier aviso temporal que requiera nuestra aplicación. Hagamos el proceso de ejemplo de un aviso de cookies.

El planteamiento cambia un poco. Si vamos a emplear ambos métodos, el de notificar lo que ocurre en la aplicación y el aviso de cookies, debemos usar una variable propia que actúe de «llave» para la cookie.

La notificación estará disponible en la vista actual y en todas aquellas vistas que tengan el fragmento de código de la cookie incluido en la plantilla hasta que se lo indiquemos. Como no podemos eliminar el contenido de la notificación desde Thymeleaft, y no sabemos el momento en el que el usuario eliminará la ventana de notificación, la variable de sesión que guarda la notificación se manejará desde el backend, mediante un controlador y una ruta que nos permita cambiar su valor.

El filtro

Comienzo añadiendo la nueva variable cookieWarning de sesión al filtro:

@Component
public class SessionFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {}

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        HttpSession session = httpRequest.getSession(true);

        if (session!= null) {

            // Variables para las notificaciones

            if (session.getAttribute("message") == null)
                session.setAttribute("message", "");

            if (session.getAttribute("messageType") == null)
                session.setAttribute("messageType", ""); 
                // Valores: "danger" u otro cualquiera = "info".

            // Cierre de notificaciones al cambiar de página

            if (session.getAttribute("messageActivated") == null)
                session.setAttribute("messageActivated", false);

            if ((boolean) session.getAttribute("messageActivated")) {
                session.setAttribute("message", "");
                session.setAttribute("messageActivated", false);
            }

            if (!Objects.equals((String) session.getAttribute("message"), ""))
                session.setAttribute("messageActivated", true);

            // Gestión de la cookie

            if (session.getAttribute("cookieWarning") == null)
                session.setAttribute("cookieWarning", true);

        }

        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {}
}

En este caso, la variable tendrá valor true por defecto, lo que indica que el fragmento de aviso de cookies debe mostrarse. Cuando la cerremos, este valor cambiará a false.

El fragmento

Podemos llamar al fragmento que mostrará la notificación cookieWarnig.html, e incluirlo en todas nuestras páginas mediante:

<div th:replace="~{fragments/cookieWarning :: cookieWarning}"></div>

Este es su código:

<div th:fragment="cookieWarning" th:if="${session.cookieWarning}" class="container mt-3 sticky-top">

    <form th:action="@{/cookie}" method="POST">

        <input type="hidden" th:name="returnUrl" th:value="${returnUrl}">

        <div class="alert alert-warning alert-dismissible fade show shadow d-flex justify-content-between" role="alert">

            <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" width="24" height="24">
                <path stroke-linecap="round" stroke-linejoin="round" d="M10.34 15.84c-.688-.06-1.386-.09-2.09-.09H7.5a4.5 4.5 0 1 1 0-9h.75c.704 0 1.402-.03 2.09-.09m0 9.18c.253.962.584 1.892.985 2.783.247.55.06 1.21-.463 1.511l-.657.38c-.551.318-1.26.117-1.527-.461a20.845 20.845 0 0 1-1.44-4.282m3.102.069a18.03 18.03 0 0 1-.59-4.59c0-1.586.205-3.124.59-4.59m0 9.18a23.848 23.848 0 0 1 8.835 2.535M10.34 6.66a23.847 23.847 0 0 0 8.835-2.535m0 0A23.74 23.74 0 0 0 18.795 3m.38 1.125a23.91 23.91 0 0 1 1.014 5.395m-1.014 8.855c-.118.38-.245.754-.38 1.125m.38-1.125a23.91 23.91 0 0 0 1.014-5.395m0-3.46c.495.413.811 1.035.811 1.73 0 .695-.316 1.317-.811 1.73m0-3.46a24.347 24.347 0 0 1 0 3.46" />
            </svg>&nbsp;&nbsp;
            
            <span class="align-middle"><strong>Atención:</strong> Este sitio usa cookies. Lea la Política de privacidad.</span>

            <button type="submit" class="btn btn-sm btn-outline-primary" data-bs-dismiss="alert" aria-label="Confirmar">OK</button>
        </div>
    </form>
</div>

Nuestra notificación de cookie se verá así:

La comprobación th:if="${session.cookieWarning}" hará que se muestre o no este fragmento, osea, que se muestre o no la notificación de cookies.

Como se aprecia, se incluye un formulario que actuará cuando el usuario cierre la notificación. Con el botón button type="submit", mediante el formulario, llamo al controlador que va a desactivar la notificación de cookie a través la ruta indicada en el formulario: <form th:action="@{/cookie}" method="POST">.

Con <input type="hidden" th:name="returnUrl" th:value="${returnUrl}"> indico, a través de la respuesta de formulario al controlador, a qué página debo dirigirme después de realizar la operación, pues, como dije, no sabemos en qué momento el usuario cerrará la notificación. Esto me permitirá volver a la página donde estaba una vez se procese el cambio del valor de la variable de sesión de la cookie.

Suelo usar de forma genérica returnUrl para indicar la ruta porque es útil para, por ejemplo, cuando llamo a un formulario y quiero saber dónde debo ir una vez enviado el contenido del formulario, como en este caso. Por ejemplo, si nuestra aplicación maneja cines, y añadimos, editamos o borramos un cine, mediante returnUrl puedo indicar al método @PostMapping qué vista mostrar tras realizar estas operaciones. Para poder hacerlo, cuando usé las vistas de crear, editar o borrar mencionadas, añado esta variable al modelo con:

model.addAttribute("returnUrl", "cinemas");

donde cinemas es la ruta a la que se debe llegar una vez el formulario de la ruta a la que vamos se procese. El método se vería así:

@GetMapping("/create")
public String createForm(Model model) {

    model.addAttribute("cinema", new Cinema());
    
    model.addAttribute("returnUrl", "cinemas");

    return "cinema/cinema-form";
}

En la carpeta controllers, creo el controlador CookieController siguiente:

@Controller
public class CookieController {

    @PostMapping("/cookie")
    public String closeCookiePolicy(HttpSession session,
        @RequestParam(value = "returnUrl", required = false) String returnUrl) {

        session.setAttribute("cookieWarning", false);

        if (!stringIsEmpty(returnUrl)) {
            return "redirect:" + returnUrl;
        } else {
            return "redirect:/";
        }
    }
}

Así, a través de la ruta /cookie puedo cambiar el valor de cookieWarning con: session.setAttribute("cookieWarning", false); y luego volver a la ruta deseada si hemos pasado el parámetro returnUrl. Ahora la notificación ya no se mostrará más.

Es importante que la ruta /cookie esté definida en nuestra configuración de seguridad. Si estamos usando Spring Security, en SecurityConfig.class debe haber algo como esto:

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(authRequest -> authRequest

            // otras configuraciones

            .requestMatchers(HttpMethod.POST, "/cookie").permitAll()

            // otras configuraciones

            .anyRequest().authenticated()
        )

        // otras configuraciones

        return http.build();
}

Con .requestMatchers(HttpMethod.POST, "/cookie").permitAll() la ruta /cookie es ahora visible y ya podemos usarla desde el fragmento para cerrar nuestra notificación.

Un ejemplo

Puedes ver el código que implementan estos métodos, tanto las notificaciones como los mensajes fijos de cookies, en el repositorio de la aplicación Cartelera DAW.

Repositorio de Cartelera DAW

Spinner loader en Thymeleaft

JavGuerra — Mon, 08 Jul 2024 00:00:00 GMT

Etiquetas: #código, #java, #spring boot, #thymeleaft

A veces, el tiempo de respuesta del servidor es alto, y el usuario puede sentir que la aplicación web no está funcionando bien. Aquí explico cómo usar un spinner loader o animación de carga propia, generada con CSS, que se active al cargar la página y permanezca activa hasta que se muestre completamente.

Esta entrada hace uso y adapta los contenidos ya explicados anteriormente en este blog en Spinner loader asíncrono, pero en este caso se simplifica el proceso al plantear una solución que no se basa en eventos asíncronos.

Manos a la obra

Lo que voy a hacer es mostrar el cargador cada vez que entramos en una página, y hasta que esta se carga completamente. Usaré JavaScript para activarlo y desactivarlo.

Necesitaré un espacio donde mostrar la animación de carga y el CSS que defina esta animación.

El fragmento

Para incluir el código necesario en nuestras vistas con Thymeleaft, creo un fragmento que llamo spinner.html como este:

<div th:fragment="spinner">
    <dialog id="zone">
        <div class="spinner" aria-label="Cargando..."></div>
    </dialog>

    <script>
        const zone = document.querySelector('#zone');

        // Activa la ventana modal
        let domContentLoadedCallback = function() {
            zone.showModal();
            document.removeEventListener('DOMContentLoaded', domContentLoadedCallback);
        };

        // Desactiva la ventana modal
        let loadCallback = function() {
            zone.close();
            window.removeEventListener('load', loadCallback);
        };

        document.addEventListener('DOMContentLoaded', domContentLoadedCallback);
        window.addEventListener('load', loadCallback);
    </script>
</div>

Puedo incluir este fragmento en cualquier parte de la plantilla Thymeleaft con:

<div th:replace="~{fragments/spinner :: spinner}"></div>

Realmente no importa en qué parte de la plantilla incluyamos el fragmento, pues va a hacer uso de dialog, una etiqueta HTML que define una ventana modal que se muestra en el centro exacto de la ventana del navegador.

<dialog id="zone"><div class="spinner" aria-label="Cargando..."></div></dialog>

Este simple código define una ventana modal identificada como zone y un div que servirá para mostrar el cargador definido a través de la clase spinner.

Mediante el código JavaScript posterior, selecciono la ventana modal zone sobre la que voy a actuar, y luego defino dos eventos, el primero hará que se muestre el cargador y el segundo que se desactive.

El primer evento se dispara cuando el HTML se ha cargado completamente (DOMContentLoaded), y el segundo cuando todos los contenidos referenciados en la página son cargados (load). Entre el primer y el segundo evento, el cargador es visible.

Con zone.showModal(); se activa la ventana modal, y con zone.close(); se desactiva. En realidad, el cargador está ahí en todo momento, pero no está visible en todo momento.

Dentro de cada función que gestiona el evento he incluido también el código para quitar el evento una vez usado.

El CSS

Con el siguiente código:

#zone {
  border: none;
  background: none;
}

#zone:focus {
  outline: none;
}

.spinner {
  margin: 0 auto;
  border: 5px solid moccasin;
  width: 36px;
  height: 36px;
  border-radius: 50%;
  border-left-color: DarkOrange;

  animation: spin 1s ease infinite;
}

@keyframes spin {
  0% { transform: rotate(0deg); }
  100% { transform: rotate(360deg); }
}

No debemos olvidar incluir algo como:

<link rel="stylesheet" href="/css/estilo.css">

en el head de las plantillas donde vayamos a usar el cargador, cambiando estilo.css y su ruta según corresponda.

El modal identificado como #zone se verá sin fondo y sin borde, osea, totalmente transparente. En él es donde se muestra el cargador. #zone tendrá el tamaño del cargador, y aparecerá centrado tanto vertical como horizontalmente en la pantalla, manteniéndose centrado aún haciendo scroll.

Con .spinner describo el aspecto del spinner loader, e indico que debe animarse infinitamente girando 360 grados cada segundo.

Realmente se trata de colorear el borde a un div, poner un color distinto al borde de uno de sus lados, redondear sus esquinas para que el div parezca un círculo y luego hacerlo girar constantemente. Simple y efectivo.

Y no necesitamos nada más. Ahora, cada vez que se cargue una página, veremos el cargador durante el tiempo que tarda en cargarse completamente.

No se recomienda abusar del cargador, ya que este puede centrar la atención del usuario, por lo que usado con moderación, en las páginas que son susceptibles de retrasar su carga, añadimos un efecto interesante y útil a nuestra aplicación y damos información al usuario de lo que ocurre.

Uso en formularios

Cuando enviamos un formulario o hacemos una petición que el backend va a tardar en procesar, también podemos activar la visualización del cargador hasta que cambie la vista. Para ello podemos añadir un evento a nuestro formulario de la siguiente manera:

<form id="myForm" th:action="@{/setCity}" method="POST">
    
    ...

    <button id="send" type="submit">Guardar</button>
</form>

<script>
    document.getElementById('send').addEventListener('click', function(event) {
        event.preventDefault();
        zone.showModal();
        document.getElementById('myForm').submit();
    });
</script>

Una vez identificados el formulario myForm y el botón de enviar send, mediante JavaScript asocio un evento que permitirá que, al hacer click en el botón de guardar, se active la ventana modal.

Con event.preventDefault(); capturo el evento de envío del formulario para poder intercalar la activación de la ventana modal con zone.showModal(); antes de enviar el formulario definitivamente con document.getElementById('myForm').submit();.

Es necesario que el fragmento spinner.html se haya incluido en la página. De otra forma podemos incluir el código del cargador ya mencionado en cualquier parte de nuestra página:

<dialog id="zone"><div class="spinner" aria-label="Cargando..."></div></dialog>

Como ya sabemos que vamos a cambiar de vista al enviar el formulario, no es necesario desactivar el evento click del formulario, pero si estamos haciendo comprobaciones el en frontend, es posible que necesitemos hacerlo cunado mostremos errores, lo que implica código de comprobaciones adicional. Si estamos usando @Valid en nuestro backend, esto no será necesario.

Un ejemplo

Puedes ver el código que implementa esta solución en el repositorio de la aplicación Cartelera DAW.

Enlaces recomendados

Info sobre la etiqueta <dialog>.
Artículo «Cómo crear un spinner loader con CSS»

Logout personalizado con Spring Security

JavGuerra — Sat, 13 Jul 2024 00:00:00 GMT

Etiquetas: #código, #java, #spring boot, #spring security, #ciberseguridad

En un artículo anterior he usado variables de sesión para guardar información de la aplicación: mensajes para el usuario, aviso de cookies… Puede que, cuando el usuario salga de su sesión, queramos conservar estos datos que seguirán siendo útiles aunque no esté autenticado. En esta entrada muestro mi solución usando Spring Security.

Se asume que el lector tiene conocimientos generales de Spring Boot y Spring Security para aplicar el contenido.

El contexto de seguridad

El primer paso en el proceso de logout que lleva a cabo Spring Security es invalidar la sesión del usuario. Esto significa que Spring Security elimina cualquier información asociada con la sesión del usuario, como datos de estado de sesión almacenados en el servidor o en cookies (borra la información, pero no la cookie). Al invalidar la sesión, se asegura de que el usuario ya no pueda acceder a la aplicación como si estuviera autenticado.

Después de invalidar la sesión, Spring Security también limpia el contexto de seguridad actual. Esto incluye eliminar cualquier token de Authentication que represente al usuario autenticado, asegurando que el usuario ya no sea reconocido como autenticado en la aplicación.

Pero en este caso no interesa ese borrado completo, sino sólo la información de autenticación. Para ello debo codificar mi propio logout limpiando el contexto de seguridad pero sin invalidar la sesión.

Tomando el control de Logout

Como sabemos, para configurar Spring Security se usa la clase SecurityConfig.class, que generalmente incluye el componente SecurityFilterChain, fundamental para establecer filtros a las peticiones HTTP que se reciben en la aplicación. En este ejemplo me centraré en la parte de su configuración relativa al logout.

@Configuration
@EnableWebSecurity
public class  SecurityConfig {

    ...

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http)  throws Exception {
        http.authorizeHttpRequests(authRequest -> authRequest

                ...

                .requestMatchers(HttpMethod.POST, "/logout").permitAll()

                .anyRequest().authenticated()
            )

            ...

            .logout(logout -> logout
                .logoutUrl("/logout")
                .permitAll()
            )

        return http.build();
    }
}

Con ... indico que el código puede ser más amplio y contener otras configuraciones.

En la línea .requestMatchers(HttpMethod.POST, "/logout").permitAll() estoy permitiendo el acceso a la ruta personalizada para llevar a cabo el logout. Realmente, esto no sería necesario al incluir .permitAll() después de logoutUrl("/logout"). Tampoco sería necesario porque la ruta /logout está disponible por defecto. No obstante, esto puede ser útil si decidimos usar otra ruta distinta a /logout en la aplicación.

Para la gestión del token del usuario, será necesario definir un controlador propio para la ruta logout. Algo similar a esto:

@Slf4j
@Controller
public class LogoutController {

    @RequestMapping("/logout")
    public String logout() {

        log.info("logout");

        SecurityContextHolder.getContext().setAuthentication(null);

        // cosas que hacer tras el cierre de sesión aquí

        return "logout";
    }
}

La información de sesión se guarda en una cookie llamada JSESSIONID, que contendrá las variables de sesión, incluido el token de autenticación.

Con SecurityContextHolder.getContext().setAuthentication(null); elimino el token de autenticación, pero sin borrar toda la información de la cookie, como las variables de sesión.

Después de esto, puedo realizar algunas acciones asociadas al cierre y redirigir al login, o como en este caso, mostrar la vista logout para mostrar un mensaje de despedida.

Refinando el logout

Al usar null elimino el token de autenticación del usuario, pero puede que, en la plantilla que devuelvo con return (logout en el caso anterior), sea necesario usar el contexto de seguridad, por ejemplo mostrando una información u otra en un fragmento de la plantilla si estamos autenticados o no. Con este método, ni sec:authorize="isAnonymous()" ni sec:authorize="isAuthenticated()" funcionarán en Thymeleaft, ya que ahora no existe el token que indique si el usuario es anónimo o está autenticado.

Esto ocurre sólo para la vista asociada al controlador que es llamada tras borrar el token, pero no ocurre así para las siguientes vistas, en las que parece que el token es regenerado como anónimo.

Entonces, si en la siguiente vista no vamos a usar la autenticación, será suficiente con usar null, pero si no es así, entonces hay que cambiar el token en vez de eliminarlo, pero Spring Boot no tiene un token por defecto que pueda usar, así que debo construir uno.

Primeramente añado el siguiente código en

@Bean
public AnonymousAuthenticationToken anonymousAuthenticationToken() {
    List<GrantedAuthority> authorities = Collections.singletonList(new SimpleGrantedAuthority("ROLE_ANONYMOUS"));
    return new AnonymousAuthenticationToken("ANONYMOUS_USER", "ANONYMOUS_USER", authorities);
}

Que me permitirá crear anonymousAuthenticationToken como un Bean. Este método es responsable de crear e inicializar el objeto AnonymousAuthenticationToken. Este token es utilizado por Spring Security para representar la autenticación de usuarios anónimos dentro de una aplicación.

El método realiza las siguientes acciones:

Inicialización de Autoridades: Primero, creo una lista (List<GrantedAuthority>) con un solo elemento, que es una instancia de SimpleGrantedAuthority con el rol "ROLE_ANONYMOUS". Las autoridades (o roles) determinan los privilegios que tiene un usuario dentro de la aplicación. En este caso, asigno al usuario anónimo el rol de ROLE_ANONYMOUS.
Creación del Token: Luego, utilizo esta lista de autoridades para construir un nuevo AnonymousAuthenticationToken, pasando también dos cadenas de texto ("ANONYMOUS_USER") como nombre y detalles del usuario. Estos valores pueden ser personalizados según sea necesario.

Ya puedo usar el token en el controlador, como se muestra:

@Slf4j
@RequiredArgsConstructor
@Controller
public class LogoutController {

    private final AnonymousAuthenticationToken anonymousAuthenticationToken;

    @RequestMapping("/logout")
    public String logout() {

        log.info("logout");

        SecurityContextHolder.getContext().setAuthentication(anonymousAuthenticationToken);

        // cosas que hacer tras el cierre de sesión aquí

        return "logout";
    }
}

Ahora sí, el usuario será anónimo, y cualquier comprobación en la plantilla Thymeleaft que incluya sec:authorize="isAnonymous()" permitirá que la etiqueta HTML que lo use sea mostrada.

Consideraciones

Tal vez podría crearse un servicio al que llamar desde el controlador para gestionar el logout, o un manejador propio CustomLogoutHandler que realice esta función de cierre de sesión sin la necesidad de crear un controlador, y que se use directamente desde SecurityConfig.class.

Se han de tener en cuenta las consideraciones de seguridad relacionadas con este método. Mantener información de la sesión de usuario una vez se lleva a cabo el logout no siempre es seguro, y se deben controlar las posibles fugas de información para evitar problemas.

Un ejemplo

Puedes ver el código que implementan esta funcionalidad en el repositorio de la aplicación Cartelera DAW.

Repositorio de Cartelera DAW

Mira también el artículo donde se usan las variables de sesión que quiero preservar:

Notificaciones con Thymeleaft

Apuntes TIC

JavGuerra — Thu, 12 Jan 2023 00:00:00 GMT

Etiquetas: #código, #php, #java, #bbdd

Incluyo en este repositorio mis apuntes sobre mis materias de estudio tanto de DAW como autodidactas. También incluyo materiales realizados para formaciones impartidas.

Nota: Esta entrada se actualizará cuando se produzcan novedades.

Apuntes

BBDD
- relacional
Infraestructura
- servidores (varios)
Programación
- JAVA
- PHP
- varios

Repositorio

Apuntes TIC

Cartelera DAW

JavGuerra — Thu, 20 Jun 2024 00:00:00 GMT

Etiquetas: #portfolio, #web, #java, #spring boot, #bootstrap, #thymeleaft, #spring security, #accesibilidad, #responsive

Recientemente he presentado mi proyecto fin de estudios de Formación Profesional de Grado Superior DAW. Era algo que llevaba aparcado durante demasiado tiempo y finalmente esta etapa se ha cerrado.

El proyecto ha consistido en una aplicación web monolítica, desarrollada en Java, usando el framework Spring Boot, y ha sido desplegada en el servicio de Railway.com.

El proyecto

El proyecto Cartelera DAW desarrolla una plataforma web para mostrar información cinematográfica cuyos usuarios potenciales son los espectadores y las distribuidoras de películas, cines y salas de proyección.

La plataforma, que está basada en Java y Spring Boot, utiliza un patrón Modelo-Vista-Controlador y una arquitectura cliente-servidor, haciendo uso del IDE IntelliJ IDEA, de Maven para la gestión del proyecto, de Git y GitHub para el versionado de código, de MySQL e Hibernate para la gestión de la base de datos y de una configuración LAMP dockerizada para las pruebas. Para el despliegue se utilizaron tecnologías como Docker y metodologías CI/CD. Para el frontend se ha empleado el gestor de plantillas Tymeleaft y Bootstrap.

Adicionalmente se proponen una serie de estrategias comerciales para garantizar la sostenibilidad del modelo empresarial del proyecto.

Se elaboró una memoria de 70 páginas y una presentación.

El objetivo era aprender y usar tecnologías nuevas no estudiadas en DAW.

La calificación final ha sido de 9 de 10, y se ha llevado a cabo en un periodo de tres semanas.

La formación previa

Pero el proyecto no partía de cero. Durante los meses de enero y febrero, y hasta el 9 de marzo de 2023, participé en un curso de especialización en Java + Spring de la Fundación Adecco dentro del Proyecto Digital School Erasmus+

Se trataba de una formación mentorizada que incluía un trabajo en grupo para desarrollar una aplicación web. En mi grupo de trabajo me encargué de la coordinación del equipo mediante Trello y de la planificación de las funcionalidades de la aplicación y las propuesta de mejora de la app. El grupo se llamaba Cinéfilos, y Cartelera DAW bebe de la estructura simple de aquella práctica que me sirvió para entender cómo funciona el framework.

El proyecto ahora presentado ha cambiado mucho desde aquella versión, tanto en su estructura como en su diseño. Partía de un código inconcluso donde sólo se habían implementado los CRUDs básicos, con fallos de integridad y sin funcionalidades mínimas, pero ahora la aplicación ha sido probada y revisada en profundidad, y cuenta con características que refuerzan sus funcionalidades.

En el curso, así como en la práctica, obtuve una calificación de 10/10.

Características

Además de los requisitos solicitados para el MVP, en la app se ha implementado:

Seguridad de rutas
Registros de usuario
Validaciones de formularios
Automatizaciones
Documentación con JavaDoc
Implementación de Logs
Notificaciones
Despliegue dockerizado

Cuenta con:

Portada dinámica
Diseño responsive
Diseño accesible
Aviso legal y privacidad
Aviso de cookies
Ayuda en línea
Spinner loader

Desarrollo y despliegue

Tanto en el desarrollo como en el despliegue ha jugado un papel importante Docker.

La BBDD MySQL y PHPMyAdmin han sido lanzados usando contenedores gestionados con la herramienta Portainer.

El despliegue se lleva a cabo tomando el código fuente y, mediante un dockerfile, construyendo la imagen del contenedor que es lanzado en el servidor.

Spring Boot contiene un servidor Tomcat encargado de servir las páginas de la aplicación.

Indicaciones de instalación

Tras clonar el repositorio, es necesario crear un usuario en la BBDD relacional llamado «cartelera-daw» con el password que deseemos. Estos datos, así como el puerto por defecto de la app (8082), pueden ser introducidos en el fichero «aplication.propieties», en la carpeta resources.

Cada vez que se inicia la aplicación, esta recarga los datos en la BBDD.

Una vez iniciada la aplicación en local, se puede acceder a ella en la dirección: http://localhost:8082

El acceso al panel de administración requiere de usuario y contraseña. Por defecto, la aplicación tiene un usuario «admin» y su contraseña es «admin».

ADVERTENCIA: Se recomienda que, tras el primer acceso, la contraseña de admin sea cambiada o se cree una nueva cuenta de usuario desde la que eliminar la cuenta «admin».

Licencia

Sobre el código fuente: GNU GENERAL PUBLIC LICENSE Version 3

Enlaces

Recursos TIC

JavGuerra — Wed, 11 Dec 2024 00:00:00 GMT

Etiquetas: #portfolio, #web, #java, #spring boot, #bootstrap, #thymeleaft, #spring security, #accesibilidad, #responsive, #selenium, #api, #swagger, #javadoc, #junit, #mockito, #docker, #jacoco, #github actions, #ci-cd, #sonarqube

Recientemente he cursado una formación con Adecco, y este es mi proyecto fin de estudios, que ha consistido en desarrollar una aplicación que permita gestionar recursos TIC y listas de recursos, para realizar los tests correspondientes, aplicando los conocimientos aprendidos, y que ha sido desplegada en el servicio de Railway.com.

El proyecto

La plataforma, que está basada en Java y Spring Boot, utiliza un patrón Modelo-Vista-Controlador y una arquitectura cliente-servidor, haciendo uso del IDE IntelliJ IDEA, de Maven para la gestión del proyecto, de Git y GitHub para el versionado de código, de MySQL, H2 y el ORM Hibernate para la gestión de la base de datos y de una configuración LAMP dockerizada para las pruebas.

Para el frontend se ha empleado el gestor de plantillas Tymeleaft y Bootstrap.

Para los tests se ha usado JUnit, Mockito, Selenium. la API se ha probado con Swagger y las estadísticas se han generado con JaCoCo y SonarQube.

Para el despliegue se utilizaron tecnologías como Docker y metodologías CI/CD con GitHub Actions.

La planificación y codificación se han llevado a cabo usando Trello.

Destacados

Además de los requisitos del MVP, se han incluido las siguientes funcionalidades:

Diseño responsive, “mobile first”
Web accesible AA. Testada con WAVE
Seguridad por diseño
Confirmaciones de borrado
Implementación de login de usuarios
Integra el editor TinyMCE
Provee API REST e interfaz Swagger
Incluye aviso legal, privacidad y cookies
Documentación la aplicación con JavaDoc
Usa el protocolo OpenGraph para RR.SS.
Manifest para móviles (PWA)
Desarrollada con Linux + Docker LAMP
Despliegue

Video

El proyecto fue presentado a empresas de tecnología, y se puede ver en el vídeo de la presentación del proyecto aquí:

Indicaciones de uso

Requisitos

Para ejecutar el proyecto se requiere:

Java 23 o superior
Maven
MySQL
Docker

Configuración

Actualmente la aplicación se ejecuta localmente en el puerto 8082.

Puede construirse un contenedor Docker con la imagen de la aplicación ejecutando el fichero docker.sh que hace uso de docker-compose para lanzar la aplicación y la BBDD que requiere.

Para generar un informe de cobertura de testing, se puede ejecutar el comando mvn site y acceder a él en el directorio target/site/jacoco/index.html.

Códice | Entradas sobre «java»

ConsoleInput kit

Lo primero: abrir y cerrar

Introducir datos por consola

El problema: .next() vs. .nextLine()

Pulse Intro para continuar

Obtener un número largo, entero, positivo

Obtener un número largo, entero, positivo por rango

Obtener una palabra

Obtener una cadena de caracteres

Obtener un Sí o No

Bonus: limpiar la consola

La clase ConsoleInput completa

Puntos fuertes de esta clase

Un ejemplo de uso

Enlaces

Notificaciones con Thymeleaft

Planteamiento

Programando notificaciones

El fragmento

Inicializando las variables message y messageType

Usando mensajes

Mensajes encadenados

Cerrando la notificación al cambiar de página

BONUS: Aviso de cookies

El filtro

El fragmento

Cerrando la notificación de cookie

Un ejemplo

Spinner loader en Thymeleaft

Manos a la obra

El fragmento

El CSS

Uso en formularios

Un ejemplo

Enlaces recomendados

Logout personalizado con Spring Security

El contexto de seguridad

Tomando el control de Logout

Refinando el logout

Consideraciones

Un ejemplo

Apuntes TIC

Apuntes

Repositorio

Cartelera DAW

El proyecto

La formación previa

Características

Desarrollo y despliegue

Indicaciones de instalación

Licencia

Enlaces

Recursos TIC

El proyecto

Destacados

Video

Indicaciones de uso

Requisitos

Configuración

Autores

Licencia

Enlaces