logisfashion

1. Descripción general

Según el pom.xml, el proyecto se describe como "Logisfashion API". Es una API REST que actúa como receptor de webhooks del proveedor logístico externo Logisfashion: recibe payloads JSON de movimientos de stock, procesos de entrada, actualizaciones de pedido e inventario, y los registra en el log. Según los propios comentarios TODO del controlador, está pensada para convertir estos payloads a CSV y subirlos por FTP, pero esa lógica no está implementada todavía.

2. Información técnica

Campo	Valor
artifactId	logisfashion
groupId	com.hawkersco
version	1.0.25
Java	25
Spring Boot	4.0.6
Tipo de artefacto	jar (ejecutable, API web de larga duración)
Módulos	No aplica (proyecto de módulo único)

3. Arquitectura y diseño

Solo 2 ficheros fuente significativos, sin capas de servicio ni repositorio:

• LogisfashionApplication — punto de entrada Spring Boot.
• controller.LogisfashionController — todos los endpoints REST.

flowchart TD
    A[Logisfashion externo] -->|PUT/POST webhooks| B[LogisfashionController]
    B -->|log.info del payload| C[Log de consola]
    B -.->|TODO sin implementar| D[Conversión a CSV + subida FTP]

No hay transformación ni persistencia real: cada endpoint recibe el cuerpo JSON como String, lo registra vía SLF4J, y devuelve una respuesta de confirmación fija, sin procesar el contenido.

4. Dependencias principales

Dependencia	Propósito
spring-boot-starter-web	API REST
com.google.code.gson:gson	Declarada para parseo JSON, sin uso visible en el controlador actual
org.json:json	Construcción de la respuesta JSON (JSONObject)

No hay dependencia de spring-boot-starter-security ni de ninguna librería de autenticación.

5. API / Endpoints

Todos bajo el prefijo /api.

Método	Ruta	Descripción	Autenticación
GET	/api/check	Health check	Pública
PUT	/api/stock-movements	Recibe datos de movimiento de stock (solo log, sin procesar)	Ninguna (ver hallazgo de seguridad)
POST/PUT	/api/inbound-processed	Notificación de entrada de producto (solo log)	Ninguna
POST/PUT	/api/order-update	Notificación de actualización de pedido (solo log)	Ninguna
POST/PUT	/api/stock-inventory	Actualización de inventario (solo log)	Ninguna

6. Integraciones externas

Sistema	Protocolo	Dirección	Detalle
Logisfashion (proveedor logístico externo)	HTTP REST (webhooks entrantes)	Entrante	Envío de eventos de stock/inbound/pedidos/inventario

No hay integraciones salientes: la conversión a CSV y la subida por FTP mencionadas en el propósito del servicio están pendientes de implementar.

7. Configuración

En producción (application-pro.properties) el token de autenticación llega por variables de entorno inyectadas como Secret de Kubernetes; en local (application.properties) el repositorio contiene un valor de prueba hardcodeado.

Clave	Descripción
server.port	Puerto de escucha (80)
auth.token.name	Nombre de la cabecera de autenticación esperada (Hawkers-LF-ApiKey)
auth.token.value	Hash BCrypt del valor esperado de la cabecera — no usado en ningún punto del código (ver hallazgo de seguridad)

⚠️ Alerta de seguridad — endpoints de escritura completamente sin autenticar

Los 4 endpoints de webhook (/api/stock-movements, /api/inbound-processed, /api/order-update, /api/stock-inventory) no aplican ninguna verificación de la cabecera Hawkers-LF-ApiKey, pese a que las propiedades auth.token.name/auth.token.value están definidas y documentadas en el propio CLAUDE.md del proyecto ("Authentication is configured but not enforced"). El controlador recibe los headers como parámetro pero nunca los compara con el valor configurado; no hay spring-boot-starter-security en el pom.xml, ni filtros, ni interceptores, ni ninguna otra capa de verificación en el repositorio. En la práctica, cualquier cliente que conozca (o adivine) la URL puede invocar estos endpoints sin credenciales.

Riesgo actual limitado porque los endpoints no persisten ni actúan sobre datos reales (la lógica de negocio está pendiente de implementar, ver sección 13), pero la falta de autenticación debe corregirse antes de completar el TODO de conversión a CSV/FTP, momento en el que peticiones no autenticadas podrían disparar procesamiento real de datos de proveedor. El valor de auth.token.value (hash BCrypt) no se ha reproducido en este documento por si acaso corresponde a un secreto real ya en uso.

8. Persistencia

No aplica a este proyecto. No hay base de datos ni almacenamiento persistente: los payloads recibidos solo se registran en el log, no se guardan en ningún sitio.

9. Procesos programados y mensajería

No aplica a este proyecto. No hay @Scheduled, listeners de colas, ni CronJob — se despliega como Deployment de larga duración que responde a webhooks entrantes en tiempo real.

10. Ejecución en local

Requisitos previos: JDK 25, Maven.

# Compilar sin tests
./mvnw -B -DskipTests clean install

# Compilar con tests
./mvnw clean install

# Ejecutar tests
./mvnw test

# Ejecutar un test concreto
./mvnw test -Dtest=LogisfashionApplicationTests

# Ejecutar el JAR
java -jar target/logisfashion-1.0.25.jar

# Build Docker
docker build -t logisfashion .

Verificación de que el servicio está operativo: GET /api/check (público).

11. Despliegue

• Imagen: construida con jib-maven-plugin (base eclipse-temurin:25-jre, containerizingMode=packaged), publicada en europe-west3-docker.pkg.dev/pi-saldum/pi-repo/logisfashion:<tag>.
• Orquestación: Kubernetes Deployment (una réplica) en el clúster GKE pi-cluster-hw, namespace pi, contenedor no privilegiado (runAsNonRoot implícito por seguridad reforzada, allowPrivilegeEscalation: false, capabilities: drop: ALL).
• CI/CD (Jenkins): pipeline real de 3 etapas — Checkout → Build & Push → Deploy to GKE (con kubectl rollout status). El CLAUDE.md describe un pipeline de 4 etapas (Build → Test → Push → Deployment), con una etapa Test vacía (jenkins/scripts/test.sh), que no se corresponde exactamente con el Jenkinsfile real de 3 etapas encontrado en este repositorio.

Job de Jenkins: https://jenkins-pi.hawkersco.net/job/logisfashion/

12. Manejo de errores y logging

No hay @RestControllerAdvice ni manejo de errores específico: cada endpoint únicamente registra el payload recibido (SLF4J) y devuelve una respuesta de éxito fija, sin validar el contenido ni capturar excepciones de parseo.

13. Notas y consideraciones

• Lógica de negocio pendiente de implementar: los 4 endpoints de webhook solo registran el payload en el log; los comentarios TODO del propio controlador confirman que la conversión a CSV y la subida por FTP —el propósito real del servicio, según su descripción— están por hacer. Actualmente el servicio no tiene ningún efecto observable más allá de dejar constancia en el log.
• Autenticación configurada pero no aplicada: ver alerta de seguridad en la sección 7 — es el hallazgo más relevante de este proyecto.
• com.google.code.gson:gson declarada sin uso aparente: el controlador usa org.json.JSONObject para construir la respuesta, no Gson; no se ha encontrado ninguna referencia a Gson en el código actual.
• CLAUDE.md verificado y consistente en su descripción de la arquitectura mínima (2 ficheros, sin capas de servicio/repositorio) y en señalar explícitamente, por sí mismo, el problema de autenticación no aplicada.