Skip to content

Sec a09 security logging - #187

Merged
J-Kanami-PS merged 11 commits into
devfrom
SEC-A09-security-logging
Jun 5, 2026
Merged

J-Kanami-PS merged 11 commits into
devfrom
SEC-A09-security-logging

Conversation

@DavidVillarM

@DavidVillarM DavidVillarM commented Jun 2, 2026 •

Copy link
Copy Markdown
Collaborator

Summary by CodeRabbit

  • New Features

    • Registro de eventos de seguridad en respuestas y auditoría de cambios de estado (asignaciones y órdenes); registro de accesos denegados y fallos de login.
  • Bug Fixes

    • Mensajes de validación estandarizados ("Error de validación" / "Datos inválidos") y manejo más consistente de parámetros validados.
  • Tests

    • Nuevos y reorganizados tests unitarios, e2e y helpers para cubrir logging, validaciones y flujos de delivery/order.

@coderabbitai

coderabbitai Bot commented Jun 2, 2026 •

Copy link
Copy Markdown
Contributor

Review Change Stack

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

Se agrega una librería de logging seguro y su middleware; se instrumentan session, orders y delivery-assignments para emitir eventos de auditoría; se unifican respuestas de validación de delivery y se centralizan/extraen helpers y harnesses de tests para e2e y unit.

Changes

Sistema de logging de seguridad y refactor de tests

Layer / File(s) Summary
Librería core de logging de seguridad
src/lib/security-logger.js, tests/unit/lib/security-logger.test.js
Nuevo módulo que normaliza claves a snake_case, sanitiza valores recursivamente (redacta JWT/Bearer, elimina caracteres de control), construye y valida líneas JSON con timestamp y expone logSecurityEvent. Tests cubren redacción, protección de campos reservados y manejo de errores sin lanzar.
Middleware de respuesta y registro en app
src/middlewares/security-log.middleware.js, src/app.js, tests/unit/middlewares/security-log.middleware.test.js
securityResponseLogger escucha res.finish, emite FORBIDDEN para status 403 con method, path, userId y role, se registra en app.js. Tests validan disparo condicional y que next() se invoque.
Instrumentación en servicios (session, orders, assignments)
src/modules/session/controllers/session.controllers.js, src/modules/users/orders/order.service.js, src/modules/delivery/delivery-assignments/delivery-assignments.service.js
Se emiten LOGIN_FAILED, ORDER_STATUS_CHANGED y ASSIGNMENT_STATUS_CHANGED. respondToAssignmentService acumula eventos en pendingAuditLogs dentro de la transacción y ejecuta los logs fuera de ella.
Validación delivery y middleware params
src/modules/delivery/delivery/delivery.validation.js, src/modules/delivery/delivery/delivery.controller.js, src/middlewares/validate.middleware.js
vehicleTypeSchema usa message en Zod; controladores de delivery devuelven message: "Datos inválidos" con details: error.issues para ZodError; validate ahora mergea datos validados en req.params.
Helpers y harnesses de tests (e2e/unit)
tests/helpers/expect-validation-error.js, tests/helpers/delivery-register.harness.js, tests/helpers/order-e2e.harness.js, tests/e2e/*, tests/unit/*
Se añade expectValidationError(res, field) y harnesses reutilizables (defineDeliveryRegisterTests, setupOrderCreateE2e) y se actualizan múltiples tests para consumirlos y simplificar mocks de Prisma.
DTOs: product tags CSV/array
src/modules/global/dtos/products/product.request.dto.js
Se introduce productTagsSchema y parseCsvTagIds; CreateProductDTO.tags y UpdateProductDTO.tags usan el nuevo schema aceptando array o CSV y evitando lanzar en transform.

Estimated Code Review Effort

🎯 4 (Complex) | ⏱️ ~45 minutos

Possibly Related PRs

Suggested Reviewers

  • SebaKisser
  • CrisNAC
  • leoAchu16

Poem

🐇 Salté entre logs y rutas,

redacté JWTs con mis patas,
403s ya no son dudas,
y los tests bailan en sus patas.
¡Brinca la rama, code rabbit canta!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed El título es directamente relevante al cambio principal: incorpora un sistema completo de logging de seguridad con auditoría de eventos sensibles.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch SEC-A09-security-logging

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Integra blacklist JWT y barrel lib/index.js de dev manteniendo logSecurityEvent en login fallido.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (1)
src/app.js (1)

80-80: ⚡ Quick win

Montá securityResponseLogger más arriba para cobertura total.

En Line 80 se registra después de otros app.use; si algún middleware previo corta con 403, no se audita. Conviene montarlo apenas creado app.

🔁 Ajuste sugerido
 const app = express();
+app.use(securityResponseLogger);

 // Seguridad HTTP con Helmet
 app.use(helmet());
@@
 app.use(express.json());
 app.use(cookieParser());
-app.use(securityResponseLogger);
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/app.js` at line 80, El middleware securityResponseLogger se monta
demasiado tarde (app.use(securityResponseLogger)); colócalo inmediatamente
después de la creación de la instancia app (inmediatamente después de const app
= express() / justo al inicializar app) y antes de cualquier otro app.use o
rutas para garantizar que capture respuestas y códigos (p.ej. 403) de
middlewares previos; busca la referencia securityResponseLogger y muévela arriba
del resto de app.use/rutas en src/app.js.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/modules/delivery/delivery-assignments/delivery-assignments.service.js`:
- Around line 298-305: Falta auditar el cambio de estado de la orden cuando se
completa la asignación: dentro del mismo flujo donde se actualiza
orders.order_status a "DELIVERED" (el bloque que ya llama a
logSecurityEvent("ASSIGNMENT_STATUS_CHANGED")), añade una llamada adicional a
logSecurityEvent para registrar el cambio de estado de la orden (por ejemplo
"ORDER_STATUS_CHANGED") incluyendo orderId (assignment.fk_order), previousStatus
(valor anterior de orders.order_status), newStatus "DELIVERED" y actorUserId
(id_user) — ubica la inserción junto al uso existente de logSecurityEvent dentro
de delivery-assignments.service.js para garantizar que tanto el cambio de
asignación como el de orden queden auditados.

In `@src/modules/session/controllers/session.controllers.js`:
- Around line 57-58: En el bloque catch que actualmente solo hace "return
next(new UnauthorizedError("Credenciales inválidas"))", añade un
registro/auditoría de seguridad para el fallo de verificación de contraseña:
captura el error lanzado por verifyPassword y emite el evento/registro
LOGIN_FAILED (incluyendo el mensaje o stack del error y el user identifier si
está disponible) antes de llamar a next(new UnauthorizedError(...)); busca la
función verifyPassword y el lugar que lanza UnauthorizedError en el controlador
de sesión para insertar la llamada al logger/auditoría (ej. emitir LOGIN_FAILED
con detalles) preservando la respuesta al cliente.
- Around line 32-35: The logSecurityEvent call uses email ?? null which leaves
empty or whitespace-only strings as non-null; normalize the email before logging
by trimming and treating empty/whitespace-only values as null (e.g., compute a
normalizedEmail from the incoming email in the login handler/controller and pass
that to logSecurityEvent), updating the branch that calls
logSecurityEvent("LOGIN_FAILED", ...) so it uses the normalized value instead of
email ?? null.

---

Nitpick comments:
In `@src/app.js`:
- Line 80: El middleware securityResponseLogger se monta demasiado tarde
(app.use(securityResponseLogger)); colócalo inmediatamente después de la
creación de la instancia app (inmediatamente después de const app = express() /
justo al inicializar app) y antes de cualquier otro app.use o rutas para
garantizar que capture respuestas y códigos (p.ej. 403) de middlewares previos;
busca la referencia securityResponseLogger y muévela arriba del resto de
app.use/rutas en src/app.js.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 5b8f2afd-aa55-447e-83aa-0cce4673b288

📥 Commits

Reviewing files that changed from the base of the PR and between 4ef0145 and 81c2019.

📒 Files selected for processing (8)
  • src/app.js
  • src/lib/security-logger.js
  • src/middlewares/security-log.middleware.js
  • src/modules/delivery/delivery-assignments/delivery-assignments.service.js
  • src/modules/session/controllers/session.controllers.js
  • src/modules/users/orders/order.service.js
  • tests/unit/lib/security-logger.test.js
  • tests/unit/middlewares/security-log.middleware.test.js

Comment thread src/modules/session/controllers/session.controllers.js
Comment thread src/modules/session/controllers/session.controllers.js
Actualiza mocks de auth y teléfono, unifica mensaje de validación Zod y corrige mocks de orders.count en e2e relacionados.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
src/modules/delivery/delivery/delivery.controller.js (1)

50-58: 💤 Low value

El mensaje fijo es coherente con el contrato del resto de la app.

Alinea la respuesta de ZodError con createAssignment y con el default de ValidationError ("Datos inválidos"), conservando details: error.issues.

Nota opcional: los otros handlers de este mismo archivo (updateDeliveryStatus, Línea 94; updateDeliveryProfile, Línea 175) siguen devolviendo error.issues[0].message. Si la intención es no filtrar detalles de validación de forma uniforme, conviene homogeneizarlos en un seguimiento.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/modules/delivery/delivery/delivery.controller.js` around lines 50 - 58,
The ZodError branch in delivery.controller.js should use the same fixed response
message as createAssignment and the default ValidationError contract, instead of
exposing a field-level message. Update the ZodError handling in the controller’s
error response to keep message as "Datos inválidos" while preserving details:
error.issues, and consider aligning updateDeliveryStatus and
updateDeliveryProfile later if you want uniform validation behavior across the
file.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/modules/delivery/delivery/delivery.controller.js`:
- Around line 50-58: The ZodError branch in delivery.controller.js should use
the same fixed response message as createAssignment and the default
ValidationError contract, instead of exposing a field-level message. Update the
ZodError handling in the controller’s error response to keep message as "Datos
inválidos" while preserving details: error.issues, and consider aligning
updateDeliveryStatus and updateDeliveryProfile later if you want uniform
validation behavior across the file.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 39f46785-66c4-4b00-8005-bb7ef6dd0fc3

📥 Commits

Reviewing files that changed from the base of the PR and between 81c2019 and 9890dcf.

📒 Files selected for processing (6)
  • src/modules/delivery/delivery/delivery.controller.js
  • src/modules/delivery/delivery/delivery.validation.js
  • tests/e2e/delivery-register.test.js
  • tests/e2e/notifications.test.js
  • tests/e2e/stock.test.js
  • tests/unit/delivery/delivery-register.test.js
✅ Files skipped from review due to trivial changes (1)
  • src/modules/delivery/delivery/delivery.validation.js

Centraliza la suite de registro delivery y el stub de orders.count en helpers reutilizables.
Usa Datos invalidos con details en lugar de issues[0].message, alineado con register y assignments.
Unifica delivery-register en e2e, extrae setupOrderCreateE2e y elimina el test unit duplicado.
Merge origin/dev, corrige validate.params merge, alinea tests e2e con middleware Zod y mantiene helpers SEC-A09.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
tests/e2e/product/products.test.js (1)

311-318: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

No fijemos un 500 como comportamiento esperado para un error de entrada.

Aceptar 500 acá hace que el test tape una excepción del handler frente a un payload inválido. Para tags con tipo incorrecto, el contrato debería seguir siendo 400 con error de validación; si hoy rompe, conviene arreglar la validación del endpoint en vez de institucionalizar el bug en el suite.

Diff propuesto para el test
   it("devuelve 400 cuando tags no es un array", async () => {
     const res = await request(app)
       .post("/products")
       .set("Cookie", `userToken=${sellerToken}`)
       .send({ name: "Test", price: 10, categoryId: 1, quantity: 5, tags: "no-array" });

-    expect(res.status).toBe(500);
+    expectValidationError(res, "tags");
   });
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/e2e/product/products.test.js` around lines 311 - 318, The test
currently expects a 500 when sending invalid payload (tags as a string) to POST
"/products" which masks a validation bug; update the assertion in the test
"devuelve 400 cuando tags no es un array" to expect 400 instead of 500, and if
the endpoint's handler (e.g., the products route/createProduct validation
middleware) actually throws a 500 for this input, fix the request validation
there so it returns a 400 validation error for invalid types (ensure the route's
schema/middleware checks that tags is an array and returns a 400 response on
failure).
🧹 Nitpick comments (3)
tests/helpers/order-e2e.harness.js (1)

57-80: ⚡ Quick win

Evitá que este harness deje implementaciones vivas entre casos.

Acá se instalan mockResolvedValue/mockImplementation sobre el prisma compartido. En las suites que lo consumen se usa vi.clearAllMocks(), y eso en Vitest no resetea implementaciones. El resultado es que prisma.$transaction, prisma.carts.findFirst y prisma.orders.count pueden filtrarse al test siguiente y volver los e2e dependientes del orden. Preferiría resetear explícitamente estos mocks antes de configurarlos, o pasar las suites consumidoras a vi.resetAllMocks() antes de reinstalar el harness.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/helpers/order-e2e.harness.js` around lines 57 - 80, Antes de volver a
instalar los mocks en este harness, reseteá las implementaciones previas para
evitar filtrado entre tests: llamá a mockReset/mockClear sobre
prisma.$transaction, prisma.carts.findFirst, prisma.orders.count y cualquier
método anidado que vayas a reasignar (por ejemplo
orders.create/orderItems.createMany/products.update/notifications.create), o
alternativamente documentá y exige que las suites consumidoras usen
vi.resetAllMocks() antes de montar este harness; luego reinstalá las
mockResolvedValue/mockImplementation como ahora (p. ej. la implementación de
prisma.$transaction).
src/middlewares/validate.middleware.js (1)

22-28: 💤 Low value

Unificar/ documentar la semántica de validate entre query, params y body
En src/middlewares/validate.middleware.js las secciones se manejan distinto: query pisa en req.validated, params hace merge en req.params creando un objeto nuevo (línea 25) y body/otros reemplazan completo req[section] (línea 27). Esto puede confundir sobre qué propiedad termina efectivamente disponible para el resto del pipeline.

  • Para params, el cambio de referencia parece de bajo riesgo: en los controllers el acceso a req.params es mayormente por destructuring (const { ... } = req.params) y no se ve uso del objeto completo por identidad (===, Object.is, const x = req.params).
  • Refactor opcional: si querés mantener consistencia y evitar el cambio de referencia, reemplazá el spread por Object.assign(req.params, result.data) o, como mínimo, documentá claramente el contrato por sección.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/middlewares/validate.middleware.js` around lines 22 - 28, En el
middleware de validación (src/middlewares/validate.middleware.js) la asignación
de resultados es inconsistente: query escribe en req.validated, params reemplaza
la referencia con req.params = { ...req.params, ...result.data } y body/otros
hacen req[section] = result.data; arregla esto o documenta el contrato.
Recomiendo sustituir el spread por una mutación de ruta para params usando
Object.assign(req.params, result.data) para mantener la misma referencia de
req.params, o si prefieres mantener el reemplazo explícito, añade un
comentario/documentación clara en el bloque que explique que params se reemplaza
y query usa req.validated; referencia las variables section, req.params y
req.validated al hacer el cambio.
tests/helpers/expect-validation-error.js (1)

1-11: ⚡ Quick win

Importá expect para no depender de globals implícitos

tests/helpers/expect-validation-error.js usa expect sin importarlo, pero vitest.config.js tiene globals: true, así que hoy no falla. Aun así, agregar el import mejora la robustez ante un cambio de configuración y mantiene consistencia con los tests que importan expect explícitamente.

Diff propuesto
+import { expect } from "vitest";
+
 export function expectValidationError(res, field) {
   expect(res.status).toBe(400);
   expect(res.body.message).toBe("Error de validación");
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/helpers/expect-validation-error.js` around lines 1 - 11, Add an
explicit import for expect and use it in the helper to avoid relying on globals:
at the top of tests/helpers/expect-validation-error.js import { expect } from
'vitest' and keep the existing expectValidationError function as-is (it
references expect), so the file no longer depends on vitest.config.js globals
and matches other tests that import expect explicitly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@tests/e2e/product/products.test.js`:
- Around line 311-318: The test currently expects a 500 when sending invalid
payload (tags as a string) to POST "/products" which masks a validation bug;
update the assertion in the test "devuelve 400 cuando tags no es un array" to
expect 400 instead of 500, and if the endpoint's handler (e.g., the products
route/createProduct validation middleware) actually throws a 500 for this input,
fix the request validation there so it returns a 400 validation error for
invalid types (ensure the route's schema/middleware checks that tags is an array
and returns a 400 response on failure).

---

Nitpick comments:
In `@src/middlewares/validate.middleware.js`:
- Around line 22-28: En el middleware de validación
(src/middlewares/validate.middleware.js) la asignación de resultados es
inconsistente: query escribe en req.validated, params reemplaza la referencia
con req.params = { ...req.params, ...result.data } y body/otros hacen
req[section] = result.data; arregla esto o documenta el contrato. Recomiendo
sustituir el spread por una mutación de ruta para params usando
Object.assign(req.params, result.data) para mantener la misma referencia de
req.params, o si prefieres mantener el reemplazo explícito, añade un
comentario/documentación clara en el bloque que explique que params se reemplaza
y query usa req.validated; referencia las variables section, req.params y
req.validated al hacer el cambio.

In `@tests/helpers/expect-validation-error.js`:
- Around line 1-11: Add an explicit import for expect and use it in the helper
to avoid relying on globals: at the top of
tests/helpers/expect-validation-error.js import { expect } from 'vitest' and
keep the existing expectValidationError function as-is (it references expect),
so the file no longer depends on vitest.config.js globals and matches other
tests that import expect explicitly.

In `@tests/helpers/order-e2e.harness.js`:
- Around line 57-80: Antes de volver a instalar los mocks en este harness,
reseteá las implementaciones previas para evitar filtrado entre tests: llamá a
mockReset/mockClear sobre prisma.$transaction, prisma.carts.findFirst,
prisma.orders.count y cualquier método anidado que vayas a reasignar (por
ejemplo
orders.create/orderItems.createMany/products.update/notifications.create), o
alternativamente documentá y exige que las suites consumidoras usen
vi.resetAllMocks() antes de montar este harness; luego reinstalá las
mockResolvedValue/mockImplementation como ahora (p. ej. la implementación de
prisma.$transaction).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: cce4a13f-544d-4de0-81c5-fe01d12d8ade

📥 Commits

Reviewing files that changed from the base of the PR and between 5e2b024 and b34f322.

📒 Files selected for processing (18)
  • src/app.js
  • src/middlewares/validate.middleware.js
  • tests/e2e/delivery-profile.test.js
  • tests/e2e/delivery-register.test.js
  • tests/e2e/delivery-status.test.js
  • tests/e2e/delivery.test.js
  • tests/e2e/notifications.test.js
  • tests/e2e/orders-delivery-reviews.test.js
  • tests/e2e/product/products.test.js
  • tests/e2e/stock.test.js
  • tests/e2e/stores.test.js
  • tests/e2e/users.test.js
  • tests/helpers/delivery-register.harness.js
  • tests/helpers/expect-validation-error.js
  • tests/helpers/order-e2e.harness.js
  • tests/unit/delivery/delivery-profile.test.js
  • tests/unit/delivery/delivery-register.test.js
  • tests/unit/dtos/misc.dto.test.js
💤 Files with no reviewable changes (1)
  • tests/unit/delivery/delivery-register.test.js
🚧 Files skipped from review as they are similar to previous changes (3)
  • src/app.js
  • tests/e2e/delivery-register.test.js
  • tests/helpers/delivery-register.harness.js

Tags invalidos devuelven 400, Object.assign en params del middleware, import explicito en helper e2e y mockReset en order harness.
Registra cambio de orden al completar asignacion, normaliza email en logs y audita fallos de verifyPassword.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/modules/global/dtos/products/product.request.dto.js`:
- Around line 13-14: Valida que el string "trimmed" contenga solo dígitos
decimales puros antes de convertirlo: replace the current Number(trimmed) +
Number.isInteger(n) check with a regex test like /^\d+$/ on trimmed, then parse
with parseInt(trimmed, 10) (or Number(trimmed) after the regex) and assert the
resulting n > 0; update the conditions around Number(trimmed) and
Number.isInteger(n) to use the regex + parseInt approach so hex/exponential
formats like "0x10" or "1e2" are rejected.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ae30b7f3-0eb7-441d-87c7-0297d40cff32

📥 Commits

Reviewing files that changed from the base of the PR and between b34f322 and 89356ec.

📒 Files selected for processing (7)
  • src/middlewares/validate.middleware.js
  • src/modules/delivery/delivery-assignments/delivery-assignments.service.js
  • src/modules/global/dtos/products/product.request.dto.js
  • src/modules/session/controllers/session.controllers.js
  • tests/e2e/product/products.test.js
  • tests/helpers/expect-validation-error.js
  • tests/helpers/order-e2e.harness.js
🚧 Files skipped from review as they are similar to previous changes (5)
  • src/middlewares/validate.middleware.js
  • tests/helpers/expect-validation-error.js
  • src/modules/delivery/delivery-assignments/delivery-assignments.service.js
  • src/modules/session/controllers/session.controllers.js
  • tests/helpers/order-e2e.harness.js

Comment thread src/modules/global/dtos/products/product.request.dto.js Outdated
Sincroniza dev reciente, conserva logging de seguridad SEC-A09 y resuelve conflictos en validate middleware y tests.
Rechaza 0x10 y notacion exponencial en parseCsvTagIds usando regex y parseInt.
…ery-register

Mantiene tests de registro delivery solo en e2e con harness (Sonar).
@sonarqubecloud

sonarqubecloud Bot commented Jun 5, 2026

Copy link
Copy Markdown

@J-Kanami-PS
J-Kanami-PS merged commit 9fe9a51 into dev Jun 5, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants