...

En las guías se indica que la protección CSRF se deshabilite ¿es correcto?

Sí, es correcto. La protección CSRF está centrada en sitios web que mantienen la sesión de usuario pero no es necesaria para servicios sin sesión y con mecanismo de autenticación vía token como lo es FundewebJS.

El mecanismo del ataque es el siguiente:

Image Added

Los ataques CSRF se basan sobre todo en las cookies que tienes en el navegador para intentar un ataque a través de otro sitio que "captura" y utiliza dichas cookies sin ser el destinatario legítimo, es importante saber que tras loguearnos en un sitio se nos establece una cookie en el navegador que le indica al servidor que ya somos un usuario autenticado por lo que ya no se nos vuelve a pedir login y podemos actuar sobre la aplicación con nuestro perfil. La protección CSRF se basa en añadir a las peticiones un token sólo conocido por el servidor y el destinatario real de las peticiones, de este modo aunque se capture la cookie no se podrá suplantar al destinatario ya que no se poseerá dicho token, el servidor aparte de la cookie validará el token en cada petición, si es incorrecto o no viene denegará dicho acceso.

En el caso de una aplicación sin sesión y en FundewebJS, tras el login se genera un token ( JWT ) que es el que valida el servidor, este token firmado no se puede modificar y sólo estará accesible para el destinatario real de la petición (importante mantener comunicaciones https), no tiene sentido activar la protección CSRF porque ya estamos introduciendo un mecanismo de validación vía token.

Sistema CON sesión:

1. Haces login
2. En la respuesta se inserta una cookie en el navegador para que mantenga la sesión (como hace el CAS)
3. Si entras en otra pestaña a "www.sitiochungo.com" y sabe cómo es tu API podrá intentar coger la cookie y actuar en nombre del usuario logueado.

¿Cómo lo soluciona la protección?: Añade un token CSRF que tiene que enviar en todas las peticiones el cliente de manera que aparte de la cookie necesitas ese token el cual sólo lo puedes obtener si eres el receptor directo de la respuesta.

Sistema SIN sesión:

1. Haces login
2. Se devuelve un token de usuario
3. Se envía y valida el token en cada petición

Un posible atacante tendría que ser el receptor de la petición para conocer el token que se está intercambiando.

Error en el pom.xml - Caracteres inválidos en el proyecto

...

Se debe a que en el proyecto hay algún carácter inválido, así que deberemos revisar en busca de alguna ñ, acentos o caracteres especiales, incluidos los comentarios. Puede pasar, por ejemplo, que al copiar y pegar se ponga algo que no se pueda sin que nos demos cuenta.

Error creating bean with name 'entityManagerFactory'

Este error, cuya primera línea nos dice esto:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: Invocation of init method failed; nested exception is javax.persistence.PersistenceException: [PersistenceUnit: default] Unable to build Hibernate SessionFactory; nested exception is org.hibernate.MappingException: Could not get constructor for org.hibernate.persister.entity.SingleTableEntityPersister

Puede deberse a un import incorrecto. En el caso que nos ha ocurrido, ha sido por importar la anotación Transient de java.beans, en vez de de javax.persistence (todo lo de persistencia debe importarse de esta librería). Como el error explica más bien poco, debemos repasar los imports a ver si esa es la causa.

Listar todos los endpoints levantados en nuestro Backend

En ocasiones es necesario obtener un listado de todos los endpoints disponibles en nuestra aplicación.
Aunque hay varias maneras de obtener esta información, como ya tenemos configurada la dependencia del Actuator en nuestras APIs, se explicará la forma de realizarlo con esta librería.

Solo hay que modificar el fichero application.properties (para local en nuestras fuentes, para los entornos en el repo de HelmChart) y añadir las siguientes propiedades:

management.endpoints.enabled-by-default=false
management.endpoint.health.enabled=true
management.endpoint.mappings.enabled=true 
management.endpoints.web.exposure.include=health,mappings

De esta forma se levanta el endpoint en el path /mappings y se podrán listar todos los endpoints levantados en la aplicación.

Query devuelve datos en local pero no en entorno

Se nos ha dado el caso de que una aplicación desplegada en local, utilizando el mismo datasource que en un entorno, no devolvía los mismos datos. En local se obtenían los datos correctamente, pero en test la respuesta del servicio rest era un objeto vacío. Para esto, primero debemos comprobar que la base de datos devuelve los datos correctamente en el backend. Si el problema es al responder al front, como en este caso, debemos revisar el application.properties. 

En este caso faltaban propiedades en el entorno de test, en concreto las siguientes:

spring.jackson.mapper.DEFAULT_VIEW_INCLUSION = true
spring.jpa.properties.hibernate.enable_lazy_load_no_trans=true
spring.datasource.driver-class-name=oracle.jdbc.driver.OracleDriver
spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.Oracle10gDialect
spring.jpa.generate-ddl = false

Esto no quiere decir que haya que copiar estas propiedades. Hay que comparar las propiedades que hay en el despliegue, en gitops, con las que tenemos en local, y en otros entornos si funciona correctamente, y añadir las que falten. En este caso, probablemente no se estuviese mapeando correctamente lo que se recibía de base de datos a la entidad java, pero no saltaba ninguna excepción por ello.

Se generan automáticamente las clases del metamodelo (clases con el nombre de entidad terminado en _)

Si tenemos este comportamiento y no es el que queremos, podemos hacer lo siguiente: en el icono del proyecto, Opción "Build path" > "Configure build path..." en la pestaña "source" he borrado dos entradas que tenía con subdirectorios "generated-sources".

(VS Code) Muchos errores en el pom

Si salen muchos errores en el pom, tipo que no puede encontrar los artefactos y cosas así, podemos probar lo siguiente:

• Comentamos la línea: <java.version>11</java.version>
• Guardamos el archivo
• En la esquina inferior derecha nos preguntará si queremos recargar las dependencias automáticamente cuando se modifique el pom. Le decimos que "sí", o que "siempre" (si ya le hemos dado a "siempre" previamente se recargará automáticamente).
• Una vez haya terminado de recargarse (mientras se recarga aparece en la barra inferior azul un simbolito dando vueltas, como que está "building"), descomentamos esa línea, y guardamos de nuevo.
• Una vez haya terminado de recargarse otra vez, puede que ya hayan desaparecido los errores y que podamos arrancar la aplicación.

Es un caso que nos ha ocurrido, no sabemos exactamente la razón por la que esto nos ha funcionado, así que tampoco podemos asegurar que funcione siempre, pero es una opción que podemos probar.

Propagar token Oauth automáticamente en clientes

Si nuestra API se autentica con tokens Oauth provinientes de MiCampus y, a su vez, hace uso de otros servicios en otras aplicaciones (por ejemplo, mis-certificados hace uso de certificados-api de otros grupos), es posible configurar los clientes REST para que propaguen automáticamente el token Oauth recibido en la petición original. Con esto se ahorra configurar manualmente el reenvío del token en cada llamada del cliente.

Puede verse el código para propagar el token en https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/bearer-tokens.html.

En esta URL se encuentra el soporte tanto para clientes WebClient como RestTemplate.