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:
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:
¿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:
Un posible atacante tendría que ser el receptor de la petición para conocer el token que se está intercambiando.
Si vemos este error en el pom, que nos lo marca en el <parent>:
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.
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.
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 ) 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.