Repository navigation
Add AI student assistant, AI usage analytics and secure CSV progress - #102
Merged
Merged
Conversation
documentation in missing endpoints
…join-code rotation
* Added base for RabbitMQ integration and added worker application to eecute the code safely * Updated AGENTS.md and added missing files * Added the main model and folder structure proposal for the bucket * Tunned the execution logic to allow executions without submitting the code * Added base logic for remote code execution and communication using rabbit MQ. Also MinIO was implemented * Added jakarta persistance, DTOs, mappers and repositories for code execution * Enhanced the worker response * Added code execution functionality in the backend, added logs for better understanding in the workflow and fixed business logic * Fixes for business logic * Moved ExecutionResult according to its context * Added max memory use via statistics from docker api * Minor fixes * Updated AGENTS.md file optimizing the token consumption * Changed the use of Long ids for UUIDs * Updated assignment logic, updated documentation * Added useful files * Minor fixes * Added security features and added endpoints for execution logic * Added enrollment number validation and minor fixes * redesigne of login, forgot-password pages, index Hero.tsx. and implement sandbox monako * Corrected landing and added teacher pages structure * Moved web code editor to student context, added execution logic * Implement resizable panels for the AssignmentPage. * Refactor admin and teacher layouts to use AppHeader component;. * Redesign auth, landing, and admin panels with new UI system - Apply new design to LoginPage, RecoveryPasswordPage (both states), Hero, Footer, Header, and HowItWorks landing components - Add blinking cursor effect (.animate-blink) to code blocks in LoginPage and Hero - Introduce AdminLayout component with icon-only sidebar and top bar (breadcrumb, search, bell, theme toggle) - Redesign AdminDashboardPage: stat cards, quick actions, recent users table, system status panel with throughput chart - Redesign CsvUploadPage: two-column layout with drop zone, inline upload button, progress section, CSV format reference, and tips panel - Update CreateUserPage to use new AdminLayout shell Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Added claude.md * feat: redesign teacher/student screens and add group management UI - Redesigned teacher screens: dashboard, create-assignment, groups list, group detail, create-group, clone-assignment - Added student screens: join-group, submission-history, execution-report - Restored ProtectedRoute on all teacher (TEACHER role) and student (STUDENT role) routes - Added group.types.ts and group.api.ts for student group data layer - Self-contained dark layout per page with sidebar, tokens (azure/yellow/imperial/french/dark-*) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: JohannTF <trejofloresjohanndaniel@gmail.com> Co-authored-by: Rodolfo-rgb <rodo.aparicio.lopez@gmail.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Addded unit and integraation tests in the backend
* Added base for RabbitMQ integration and added worker application to eecute the code safely * Updated AGENTS.md and added missing files * Added the main model and folder structure proposal for the bucket * Tunned the execution logic to allow executions without submitting the code * Added base logic for remote code execution and communication using rabbit MQ. Also MinIO was implemented * Added jakarta persistance, DTOs, mappers and repositories for code execution * Enhanced the worker response * Added code execution functionality in the backend, added logs for better understanding in the workflow and fixed business logic * Fixes for business logic * Moved ExecutionResult according to its context * Added max memory use via statistics from docker api * Minor fixes * Updated AGENTS.md file optimizing the token consumption * Changed the use of Long ids for UUIDs * Updated assignment logic, updated documentation * Added useful files * Minor fixes * Added security features and added endpoints for execution logic * Added enrollment number validation and minor fixes * redesigne of login, forgot-password pages, index Hero.tsx. and implement sandbox monako * Corrected landing and added teacher pages structure * Moved web code editor to student context, added execution logic * Implement resizable panels for the AssignmentPage. * Refactor admin and teacher layouts to use AppHeader component;. * Redesign auth, landing, and admin panels with new UI system - Apply new design to LoginPage, RecoveryPasswordPage (both states), Hero, Footer, Header, and HowItWorks landing components - Add blinking cursor effect (.animate-blink) to code blocks in LoginPage and Hero - Introduce AdminLayout component with icon-only sidebar and top bar (breadcrumb, search, bell, theme toggle) - Redesign AdminDashboardPage: stat cards, quick actions, recent users table, system status panel with throughput chart - Redesign CsvUploadPage: two-column layout with drop zone, inline upload button, progress section, CSV format reference, and tips panel - Update CreateUserPage to use new AdminLayout shell Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Added claude.md * feat: redesign teacher/student screens and add group management UI - Redesigned teacher screens: dashboard, create-assignment, groups list, group detail, create-group, clone-assignment - Added student screens: join-group, submission-history, execution-report - Restored ProtectedRoute on all teacher (TEACHER role) and student (STUDENT role) routes - Added group.types.ts and group.api.ts for student group data layer - Self-contained dark layout per page with sidebar, tokens (azure/yellow/imperial/french/dark-*) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feat(student): connect API endpoints and enforce business rules - Add shared studentRequest client (student/api/client.ts) replacing duplicated authHeaders/parseResponse in each API file - Refactor assignment, execution and group APIs to use the shared client - Migrate StudentDashboardPage from mock getGroups() to real listMyGroups() - Update GroupRow to use ClassGroup (isActive/archived) instead of Group - Add launchDate, closeDate and validationStatus to Assignment type - Disable Submit/Run in AssignmentPage when past closeDate, before launchDate, or validationStatus != READY; show inline status banner - Fix SubmissionHistoryPage countdown to use closeDate (hard cutoff) and show dueDate separately with late indicator - Add open/late/closed/upcoming state badges to StudentDashboardPage assignment rows; fix inprogress filter tab - Align ClassGroup with backend pattern (isActive + archived fields) - Remove dead groups.api.ts mock and getGroups() from dashboard.api - Create missing dashboard/types/dashboard.types.ts Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: JohannTF <trejofloresjohanndaniel@gmail.com> Co-authored-by: Rodolfo-rgb <rodo.aparicio.lopez@gmail.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
and teacher features. Sandbox works as expected
This reverts commit a201c67.
* fix(security): derive rate-limit key from trusted client IP
- Problema: RateLimitAspect.getClientKey() tomaba el primer segmento de X-Forwarded-For, un header controlado por el cliente, sin verificar proxy de confianza.
- Vulnerabilidad mitigada: bypass total del rate limiting. Rotando el header se obtenía un bucket nuevo por petición, anulando los límites de login (fuerza bruta de credenciales), /recovery-password/reset (spraying de tokens) y /forgot (bombardeo). Era el único control anti-fuerza-bruta.
- Cambios: RateLimitAspect.java ahora usa request.getRemoteAddr() por defecto y solo honra X-Forwarded-For cuando ratelimit.trust-forwarded-for=true; nueva propiedad en application.properties (default seguro false, override por env RATELIMIT_TRUST_FORWARDED_FOR); nuevo RateLimitAspectTest (4 casos).
- Efecto secundario esperado: en tu despliegue detrás de proxy de confianza debes poner RATELIMIT_TRUST_FORWARDED_FOR=true en el entorno; si no, todos los clientes tras el proxy compartirían la IP del proxy y el límite sería global.
* fix(security): scope rate-limit buckets per endpoint
Problema: RateLimitService.resolveBucket() usaba computeIfAbsent con una clave que era solo la IP del cliente. El primer endpoint que tocaba una IP fijaba la capacidad del bucket, y el limit/duration de los demás endpoints se ignoraba.
Vulnerabilidad/defecto mitigado: los límites se cruzaban entre endpoints. Un estudiante que tocaba /api/execution/check (10/60) obtenía luego 10 intentos/min en /api/auth/login (inflación del límite más estricto); e inversamente, tocar /forgot (3/300) primero estrangulaba todos los endpoints para esa IP (DoS entre endpoints, agravado tras NAT).
Cambios:
- RateLimitAspect.java: la clave del bucket ahora es compuesta, firma-del-endpoint | IP (nuevo helper bucketKey(...)). Así cada endpoint obtiene su propio bucket, creado con su limit/duration correctos en el primer acceso. RateLimitService no necesitó cambios.
- RateLimitAspectTest.java: 2 pruebas nuevas (endpoints distintos → claves distintas; mismo endpoint+cliente → misma clave).
* fix(security): handle invalid JWT tokens without 500 responses
Problema: JWTAuthenticationFilter.doFilterInternal() llamaba a extractClaim(...), loadUserByUsername(...) y isTokenValid(...) sin capturar excepciones. Como el filtro corre antes del DispatcherServlet, esas excepciones (MalformedJwtException, SignatureException, ExpiredJwtException, UsernameNotFoundException) escapaban del alcance de @RestControllerAdvice y terminaban en HTTP 500 con traza.
Vulnerabilidad/defecto mitigado:
- Cada token expirado normal (expiración de 24h) devolvía 500 en vez de 401/403 → rompía el manejo de sesión del SPA.
- Oráculo 500-vs-4xx y amplificación de CPU/logs por tokens basura no autenticados.
Cambios (JWTAuthenticationFilter.java):
- El intento de autenticación se movió a un método privado authenticate(...) envuelto en un único try/catch (JwtException | IllegalArgumentException | UsernameNotFoundException); ante cualquiera de ellas se deja la petición sin autenticar y se continúa la cadena.
- filterChain.doFilter(...) se invoca exactamente una vez al final.
- Se eliminó la comprobación muerta userDetails == null (loadUserByUsername nunca devuelve null, lanza excepción).
* fix(security): redact private expected outputs from student execution reports
Problema: GET /api/execution/check/{id}/report devolvía el ExecutionReport verbatim. En entregas DEFINITIVE, el worker escribe en cada TestCaseResult la salida esperada del caso privado (en expectedOutput y embebida en feedback, p. ej. "Line N mismatch: expected 'X', got 'Y'"). Como el estudiante es el iniciador, authorizeExecutionRead le permitía leer esos datos.
Vulnerabilidad mitigada: fuga de las salidas esperadas de los casos de prueba privados al estudiante, contradiciendo llms/backend/groups/README.md ("Tareas y ejemplos", regla 4: casos y salidas esperadas son privados).
Cambios (ExecutionRequestService.java):
- Al servir el reporte, si la ejecución es DEFINITIVE y el lector no es el propietario del grupo, se limpian expectedOutput, actualOutput y feedback de cada TestCaseResult (se conservan estado, tiempos, memoria y los conteos globales). El propietario sigue viendo el reporte completo; las ejecuciones PRACTICE no se tocan (sus casos los aporta el propio estudiante).
- Refactor de apoyo: authorizeExecutionRead ahora recibe el User ya resuelto (nuevo helper requireAuthenticatedUser), y la comprobación de propietario se extrajo a isGroupOwner(...), reutilizada por la redacción. Se eliminó una búsqueda de usuario duplicada.
* fix(security): require explicit credentials for bootstrap super admin
Problema: AdminInitializer creaba un SUPER_ADMIN usando defaults committeados admin@codehive.com / Admin@12345 (en la anotación @value y en application.properties), con temporaryPassword = false.
Vulnerabilidad mitigada: un despliegue que olvidara configurar las variables arrancaba con una cuenta super admin de credenciales públicas conocidas (toma de control total). Verificado antes: el .env fija ADMIN_PASSWORD pero no ADMIN_EMAIL, por lo que el correo por defecto estaba activo.
Cambios:
- application.properties: eliminados los defaults inseguros; ahora son requeridos (${ADMIN_EMAIL:} / ${ADMIN_PASSWORD:}, sin literal).
- AdminInitializer: fail-fast al arranque si email o password están vacíos, y rechazo explícito del valor histórico Admin@12345. Sólo tras validar se comprueba la
existencia y se crea el admin. Se quitaron los literales inseguros
Efectos secundarios (acción requerida):
- ⚠️ Debes añadir ADMIN_EMAIL a tu .env (hoy no está); si no, el backend no arrancará (fail-closed intencionado). Igualmente, ADMIN_PASSWORD no puede ser
Admin@12345.
- El perfil test ya define email/password válidos, así que los tests no se ven afectados.
- Las cuentas admin ya existentes no se ven alteradas (el inicializdmin ya existe).
Prueba nueva (AdminInitializerTest): password en blanco / email en → IllegalStateException sin guardar; config válida → creaSUPER_ADMIN; admin ya existente → no crea.
* fix(security): decouple CSV import execution from websocket message
Problema: submitCsvJob solo encolaba un Runnable; el alta masiva de usuarios (privilegiada) se ejecutaba cuando cualquier cliente enviaba el taskId por el WebSocket (handleTextMessage → task.run()). El endpoint /ws/** es permitAll, así que un cliente no autenticado que conociera/filtrara el taskId disparaba la creación de cuentas; además, si nadie se conectaba, el job se descartaba en silencio a los 5 minutos.
Vulnerabilidad mitigada: ejecución de una operación privilegiada a través de un canal no autenticado, y pérdida silenciosa de la operación. También elimina el byte[] del CSV retenido en memoria durante el TTL.
Cambios:
- CsvRegistrationService.submitCsvJob: ahora ejecuta processAsync directamente en el executor @async (vía el proxy selfProvider) y devuelve el taskId. El WebSocket queda como canal de progreso únicamente.
- CsvProgressWebSocketHandler: eliminado todo el mecanismo de disparo (queueTask, pendingTasks, el ScheduledExecutorService, el TTL y @PreDestroy). handleTextMessage solo registra la sesión para recibir progreso.
Efectos secundarios: el progreso ahora es best-effort — el cliente debe abrir el WebSocket y suscribirse con el taskId justo tras recibir el 202; los mensajes emitidos antes de la suscripción se descartan (la operación en sí ya no depende del socket). El alta ocurre siempre, conecte o no el cliente.
Nota: el secuestro de canal / crecimiento no acotado del mapa (taskSessions) y la PII en los mensajes se abordan en los siguientes sub-incrementos A6b y A6c.
Prueba nueva (CsvRegistrationServiceTest): submitCsvJob ejecuta processAsync de inmediato y no interactúa con el handler WebSocket.
* fix(security): bound CSV progress websocket session state
Problema: handleTextMessage sobrescribía el único atributo taskId de la sesión en cada mensaje, pero afterConnectionClosed sólo eliminaba el último → una conexión que enviara N taskId distintos dejaba N−1 entradas huérfanas permanentes en taskSessions (cada una con referencia a la sesión). Sin validación del payload, un cliente anónimo podía insertar entradas arbitrarias/grandes → agotamiento de memoria.
Vulnerabilidad mitigada: DoS por crecimiento no acotado del mapa de sesiones desde un endpoint no autenticado.
Cambios (CsvProgressWebSocketHandler):
- Se valida que el payload sea un taskId con formato UUID (longitud 36 + UUID.fromString); los mensajes malformados se ignoran (rechaza payloads basura/grandes antes de almacenarlos).
- Una sola suscripción por sesión: al recibir un taskId nuevo se elimina el mapeo previo de esa sesión, de modo que el mapa no crece más de una entrada por conexión.
- El cierre y completeTask usan la eliminación condicional remove(key, session) (atómica) para no borrar el mapeo de otra sesión en una carrera.
Efectos secundarios: ninguno para el cliente legítimo (envía un único taskId UUID). El secuestro de canal por un tercero que conozca el taskId sigue mitigado únicamente por su aleatoriedad (UUID); reducir la PII expuesta en los mensajes es el siguiente sub-incremento A6c.
Prueba nueva (CsvProgressWebSocketHandlerTest): payload no-UUID no se registra; UUID válido sí; una segunda suscripción reemplaza a la primera (mapa de tamaño 1); el cierre elimina la suscripción.
* fix(security): remove PII from CSV progress messages
Problema: los mensajes de error por fila incrustaban el valor real del correo y la boleta, p. ej. "Row N: Email 'x@y.com' is already registered" y "Row N: Duplicate enrollment number '...' in CSV". Al viajar por el canal WebSocket (observable por un tercero que conozca el taskId), esto filtraba PII y actuaba como oráculo de "usuario existente confirmado" sobre la lista subida.
Vulnerabilidad mitigada: exposición de PII (correos/boletas) y confirmación de existencia de usuarios a través del canal de progreso.
Cambios (CsvRegistrationService.processRow): los cuatro mensajes que echoaban valores ahora referencian solo la fila y el campo, sin el dato:
- "Row N: Duplicate email in CSV"
- "Row N: Duplicate enrollment number in CSV"
- "Row N: Email is already registered"
- "Row N: Enrollment number is already registered"
El administrador que sube el archivo sigue teniendo el contexto (conoce la fila N de su propio CSV), pero el valor ya no viaja por el socket.
Efectos secundarios: ninguno funcional; solo cambia el texto de los mensajes de error (sin el valor). Las validaciones a nivel de campo ("email is invalid", "name is empty") ya no exponían valores y se conservan igual.
Prueba nueva (CsvRegistrationServiceTest): al procesar una fila connsajes de progreso contienen "already registered" pero no el correoni la boleta.
* fix(security): HUGE CHANGE!! invalidate outstanding JWTs on password change
Problema: resetPassword y updatePassword solo reescribían el hash. Los JWT son HS256 stateless (sesión STATELESS), así que un token robado seguía siendo válido hasta 24h después de que la víctima recuperara/cambiara su contraseña.
Vulnerabilidad mitigada: el flujo de "recuperar mi cuenta" no expulsaba al atacante que ya tenía un token.
Cambios:
- User: nuevo campo tokenVersion (int, @ColumnDefault("0") para que la columna se agregue de forma segura vía ddl-auto=update sobre filas existentes en Postgres).
- AuthService.generateToken: añade el claim tokenVersion con el valor actual del usuario.
- JwtUtil.extractTokenVersion: lee el claim (ausente → 0, para no invalidar en masa las sesiones al desplegar).
- JWTAuthenticationFilter: tras validar firma/expiración y usuario activo, rechaza el token si su tokenVersion no coincide con el del usuario.
- AuthService.updatePassword y RecoveryPasswordService.resetPassword: incrementan user.tokenVersion al persistir la nueva contraseña.
Efectos secundarios:
- Cambiar o resetear la contraseña invalida todos los JWT previos de ese usuario, incluida la sesión actual en /me/password (el usuario deberá reautenticarse). En el flujo de reset (no autenticado) no hay downside.
- Los tokens emitidos antes del despliegue no se invalidan en masa (claim ausente se trata como 0 = versión inicial); sólo dejan de valer cuando el usuario cambia su contraseña.
Pruebas nuevas:
- JwtUtilTest: extractTokenVersion con y sin claim.
- AuthServiceTest / RecoveryPasswordServiceTest: updatePassword y rnVersion.
- JWTAuthenticationFilterIntegrationTest: un token emitido antes del cambio deja de autenticar tras subir la versión (mientras uno nuevo sí).
* 🔧 fix(security): HUGE CHANGE!! store password-reset tokens hashed
Problema: PasswordResetToken.token guardaba el token en texto plano y era la clave de búsqueda; el correo llevaba ese mismo valor. La BD contenía el equivalente-contraseña en claro.
Vulnerabilidad mitigada: cualquier lectura de la BD (dump, réplica, backup, logs) entregaba tokens de toma de control directamente usables. Ahora la BD solo guarda un digest irreversible.
Cambios (RecoveryPasswordService):
- Al crear: se genera un token aleatorio, se persiste su hash SHA-256 y se envía el token crudo por correo.
- Al resetear: se hashea el token entrante y se busca por el hash (findByToken(hashToken(token))).
- Nuevo helper privado hashToken (SHA-256 → hex). La entidad PasswordResetToken no cambia (la columna ahora almacena el hash de 64 caracteres, cabe en el varchar(255) por defecto).
Efectos secundarios: los tokens de reset ya emitidos antes del despliegue dejan de ser válidos (la búsqueda es por hash). Dado que expiran a los 15 minutos y son de un solo uso, el impacto es nulo en la práctica.
Pruebas:
- RecoveryPasswordServiceTest: el token guardado es el SHA-256 del crudo emitido (no el crudo); resetPassword busca por el hash.
- Se actualizó RecoveryPasswordControllerIntegrationTest para reflejar el flujo real (guarda el hash en el setup, envía el crudo en la petición).
* fix(security): restrict CORS to configured frontend origins
Problema: SecurityConfig usaba addAllowedOriginPattern("*") junto con setAllowCredentials(true), lo que hacía que Spring reflejara cualquier Origin en Access-Control-Allow-Origin y emitiera Access-Control-Allow-Credentials: true, con CSRF deshabilitado.
Vulnerabilidad mitigada: eliminaba el aislamiento de origen del navegador — cualquier sitio podía hacer peticiones cross-origin con credenciales y leer las respuestas. Se volvería un problema de session-riding directo si se introdujeran cookies. Además era incoherente con la allowlist ya presente en el WebSocket.
Cambios (SecurityConfig): los orígenes ahora se leen de la propiedad frontend.url (mismo patrón que WebSocketConfig, split("\\s*,\\s*")) y se aplican con setAllowedOrigins(...) explícitos. Se conservan métodos, headers y credenciales.
Efectos secundarios:
- Producción debe tener FRONTEND_URL correctamente configurada (tu .env ya la fija en http://localhost:5173); admite varios orígenes separados por coma. Si no se configura, el valor resuelto es defaultFrontendUrl, que no coincide con ningún origen real → falla cerrado (bloquea CORS) en lugar de abrirse.
Prueba nueva (CorsConfigIntegrationTest): un preflight desde el origen configurado (http://localhost:3000 en el perfil test) recibe Access-Control-Allow-Origin; uno desde un origen no listado no lo recibe.
* fix(security): stop leaking internal exception details in responses
Problema: handleGenericException devolvía ex.getMessage() al cliente para cualquier excepción no mapeada, y handleHttpMessageNotReadable devolvía ex.getCause().getMessage(). Esto exponía nombres de tablas/columnas/constraints, fragmentos SQL, claves de objetos MinIO, mensajes NPE de Java 21, estructura de paquetes y valores de enums. Además, los errores genuinos de servidor no se registraban.
Vulnerabilidad mitigada: divulgación de información interna en las respuestas de error (500 y cuerpo JSON malformado).
Cambios (GlobalExceptionHandler):
- Se añadió un Logger; handleGenericException ahora registra la excepción completa (con traza) en el servidor y devuelve un mensaje genérico ("Internal server error") al cliente.
- handleHttpMessageNotReadable devuelve "Malformed request body" sin exponer la causa del parser.
Efectos secundarios: los clientes ya no reciben detalles internos en 500 ni en JSON malformado; la información de diagnóstico queda en los logs del servidor. Los demás handlers específicos (validación, credenciales, tokens, rate limit, etc.) no se tocaron, así que sus mensajes de negocio se conservan.
Prueba nueva (GlobalExceptionHandlerTest): el handler genérico devuelve 500 con "Internal server error" sin el detalle interno; el de cuerpo malformado devuelve "Malformed request body" sin los internos del parser.
* fix(security): fail fast on weak or missing JWT secret
Problema: security.jwt.secret tenía un default committeado defaultSecret (débil y ni siquiera Base64 válido de 256 bits), y JwtUtil no validaba la longitud de la clave al arranque (fallaba tarde, en el primer uso del token).
Vulnerabilidad mitigada: un despliegue sin JWT_SECRET firmaría con una clave predecible/degradada → falsificación de tokens de autenticación. Ahora es imposible arrancar con una clave insegura.
Cambios:
- JwtUtil: nuevo @PostConstruct validateSecret() que decodifica el Base64 y exige ≥ 32 bytes (256 bits); lanza IllegalStateException si el secreto es ausente, no-Base64 o corto.
- application.properties: eliminado el default inseguro; security.jwt.secret=${JWT_SECRET:} (requerido, sin literal).
Efectos secundarios:
- ⚠️ JWT_SECRET debe estar configurada con un Base64 de ≥ 32 bytes; si no, el backend no arranca (fail-fast con mensaje claro). Tu .env ya tiene un JWT_SECRET de 43 caracteres (32 bytes), así que producción cumple.
- El perfil test ya define un secreto válido, por lo que todos los tests de integración arrancan correctamente.
Prueba nueva (JwtUtilTest): validateSecret rechaza secreto corto y en blanco, y acepta uno de ≥ 256 bits.
* fix(security): equalize login timing for unknown accounts
Problema: en AuthService.login, un usuario inexistente lanzaba la excepción sin ejecutar BCrypt, y un usuario inactivo saltaba BCrypt por el corto-circuito ||. Esto creaba un oráculo de tiempos que permitía distinguir {no existe} / {existe inactivo} / {existe activo} midiendo la latencia de la respuesta. Al aceptar boletas (estructuradas/secuenciales) como identificador, el espacio de enumeración es pequeño y recorrible.
Vulnerabilidad mitigada: enumeración de cuentas por tiempos en /api/auth/login.
Cambios (AuthService):
- Siempre se ejecuta una comparación BCrypt: si el usuario no existe, se compara contra un hash dummy precomputado (DUMMY_HASH); si existe, contra su hash real. Sólo después se decide el resultado (user == null || !isActive || !passwordMatches → credenciales inválidas).
- El mensaje uniforme ("Invalid credentials") se conserva.
Efectos secundarios: el coste de un login fallido por "usuario inexistente" o "inactivo" ahora es equivalente al de una contraseña incorrecta (una operación BCrypt), eliminando la señal de tiempo dominante. El residual (latencia de la consulta a BD) es despreciable frente a BCrypt.
Pruebas:
- Se actualizó login_WithNonExistentEmail_...: ahora verifica que sí se ejecuta matches(...) (antes afirmaba never()), y que no se emite token.
- Nueva login_WithInactiveUser_...: usuario inactivo lanza credenciales inválidas pero igualmente ejecuta la comparación.
* fix(security): send password-reset email asynchronously
Problema: MailSenderService.sendPasswordResetEmail era síncrono, a diferencia de sendWelcomeEmail. En el flujo /forgot, cuando el usuario existe se hacía una conexión/envío SMTP síncrono; cuando no existe se retornaba tras una consulta. Esa diferencia (típicamente cientos de ms) derrotaba el cuerpo de respuesta uniforme y permitía enumerar cuentas por tiempos.
Vulnerabilidad mitigada: enumeración de cuentas por tiempos en /api/recovery-password/forgot.
Cambios (MailSenderService): sendPasswordResetEmail ahora es @async("welcomeEmailExecutor") (mismo executor que el welcome) y envuelve su cuerpo en try/catch registrando fallos, igual que sendWelcomeEmail. La respuesta de /forgot ya no depende de la latencia SMTP.
Efectos secundarios:
- El envío del correo de reset ya no bloquea la respuesta; un fallo de SMTP se registra en logs y no interrumpe el flujo (el usuario puede volver a solicitar el reset, igual que con el welcome).
- El token se pasa como parámetro (no hay lectura de BD en el hilo async), así que no hay problema de commit/transacción.
Prueba nueva (MailSenderServiceAsyncTest): sendPasswordResetEmail ejecuta el envío en un hilo del executor (welcome-email-*), distinto del hilo llamante.
* fix(security): rate-limit authenticated password changes
Problema: PUT /api/auth/me/password no tenía @ratelimit. Cada intento verifica currentPassword con un BCrypt completo, sin límite.
Vulnerabilidad mitigada: fuerza bruta del currentPassword con un JWT robado o una sesión de kiosco, y amplificación de CPU (1 petición = 1 BCrypt) usable como vector DoS.
Cambios (AuthController): se añadió @ratelimit(limit = 5, duration = 300, ...) al endpoint (5 intentos por 5 minutos, coherente con reset/signup) y la respuesta 429 documentada en OpenAPI. Reutiliza el aspecto de rate limiting ya endurecido en A1/A2 (clave endpoint | IP).
Efectos secundarios: ninguno para el uso normal; sólo se limita el abuso. La clave sigue siendo por IP+endpoint (el keying por principal quedaría para una mejora futura del aspecto, no requerida aquí).
Prueba nueva (AuthControllerRateLimitTest): verifica por reflexión que updatePassword está anotado con @ratelimit con limit/duration positivos. (El aspecto está deshabilitado bajo el perfil test, por lo que se valida la anotación en vez del 429 en vivo, consistente con el resto del proyecto.)
* fix(groups): enforce writability when removing students
Problema: GroupService.removeStudent sólo llamaba a requireOwnedGroup, a diferencia de update/rotateJoinCode que además llaman a requireWritable. El propietario podía remover estudiantes de un grupo archivado o eliminado lógicamente, contra la regla documentada "archivado = solo lectura" (llms/backend/groups/README.md, ciclo de vida de grupos).
Riesgo mitigado: desviación de la invariante de solo-lectura (es un bug de regla de negocio; owner-only, no un salto de control de acceso). Alinea el comportamiento con la documentación.
Cambios (GroupService.removeStudent): se añadió requireWritable(group) tras la comprobación de propiedad. requireWritable ya cubre ambos casos (eliminado lógico → "Group is deleted"; archivado → "Group is archived and read-only"), devolviendo 400.
Efectos secundarios: remover un estudiante de un grupo archivado/eliminado ahora responde 400 en vez de aplicar el cambio; en grupos activos y no archivados funciona igual que antes.
Pruebas actualizadas/nuevas:
- GroupServiceTest: se reemplazó el test que documentaba la conductjectsArchivedAndDeletedGroups (rechaza ambos) yremoveStudentSucceedsOnActiveWritableGroup (camino feliz).
- GroupControllerIntegrationTest: archivedGroupRejectsChangesInclud 400 en la remoción y que la inscripción permanezca ACTIVE.
* fix(security): add explicit scope checks to admin user mutations
Problema: update, deactivate y restore en AdminUserController no tenían @PreAuthorize a nivel de método; sólo aplicaba la anotación de clase hasAuthority('ADMIN'). El gate de scope real vivía únicamente en AdminUserService.requireMutationPermission. Una regresión en el servicio degradaría estas operaciones silenciosamente a "cualquier admin".
Riesgo mitigado (defensa en profundidad): se añade una segunda barrera declarativa, de modo que un admin sin ningún scope de gestión de usuarios no alcanza el endpoint aunque el chequeo de servicio fallara.
Cambios (AdminUserController):
- update (PATCH): hasAuthority('ADMIN') and hasAnyAuthority('UPDATE_USERS', 'UPDATE_ADMINS').
- deactivate (DELETE) y restore (POST /restore): hasAuthority('ADMIN') and hasAnyAuthority('MANAGE_USER_STATUS', 'MANAGE_ADMIN_STATUS').
Son gates gruesos (por eso hasAnyAuthority): el scope preciso según el rol del objetivo (usuario vs admin), la protección de auto-gestión y la del último superadmin siguen decidiéndose en el servicio. SUPER_ADMIN expande a todos los scopes, así que no se ve afectado.
Efectos secundarios: ninguno en el camino de aceptación (quien ya pasaba el servicio tiene los scopes requeridos). Un admin con ADMIN pero sin ningún scope relevante ahora recibe 403 en la anotación en vez de en el servicio — mismo código de estado.
Prueba nueva (AdminUserControllerIntegrationTest): un admin con MANAGE_USER_STATUS/MANAGE_SCOPES pero sin UPDATE_* recibe 403 al intentar PATCH de actualización.
* feat(metrics): expose per-group self metrics to students
Qué se agregó: nuevo endpoint de auto-consulta para que un estudiante vea su propio desempeño agregado en un grupo.
Contrato nuevo:
- GET /api/groups/{groupId}/metrics/me → SuccessResponse<StudentMetricsDTO> (mis agregados: publishedAssignments, submittedCount, completionRate, lateCount, averageScore, gradedAssignments, totalAttempts, missingAssignmentIds, + mi identidad).
- 200 inscrito · 403 no inscrito · 404 grupo inexistente/eliminado · 401 sin JWT.
Cambios:
- GroupMetricsService: nuevo myGroupMetrics(groupId, email) que reutiliza loadGroupSnapshot, publishedAssignments, percent, averageNormalizedScore, fullName, y un gate nuevo requireActiveEnrollment(...) (usuario del JWT + inscripción ACTIVE + grupo isActive, si no 403/404). Calcula la fila del alumno autenticado igual que el cálculo docente, filtrando calificaciones a solo RETURNED (los borradores no cuentan en averageScore ni gradedAssignments). Nuevo record interno StudentContext.
- StudentMetricsController (nuevo, @tag "Student Metrics"), método me(...) con @PreAuthorize("hasAuthority('STUDENT')"), separado del controlador docente.
Diseño clave (diferencias con el panel docente): autorización por inscripción activa (no propiedad); solo datos propios; calificaciones solo devueltas. Se reutiliza el DTO StudentMetricsDTO existente tal cual.
Efectos secundarios: ninguno sobre las métricas docentes; solo se añade superficie nueva de lectura.
Prueba nueva (StudentMetricsControllerIntegrationTest, 5 casos): alumno inscrito con entrega/AC/calificación devuelta ve sus agregados; alumno sin entrega → ceros y averageScore null; calificación en borrador oculta (score null, graded 0); alumno no inscrito → 403; grupo eliminado → 404.
* feat(metrics): expose per-assignment self metrics to students
Contrato nuevo:
- GET /api/groups/{groupId}/metrics/me/assignments → SuccessResponse<List<StudentAssignmentMetricsDTO>>, una fila por tarea publicada del grupo, ordenada por createdAt desc.
- 200 inscrito · 403 no inscrito · 404 grupo inexistente/eliminado · 401 sin JWT.
Cambios:
- Nuevo DTO StudentAssignmentMetricsDTO (model/dto/metrics/): assignmentId, title, dueDate, closeDate, maxPoints, workStatus, currentSubmissionId, deliveredLate, attempts, verdict, timeMs, memoryMb, grade (reutiliza AssignmentMetricsDetailDTO.GradeSummary, solo si RETURNED).
- GroupMetricsService.myAssignmentMetrics(groupId, email): mismo gate requireActiveEnrollment de S1; reutiliza el GroupSnapshot (sin consultas nuevas — las filas de proyección ya traen assignmentId/workStatus), arma la fila del alumno autenticado por cada tarea publicada, con calificaciones solo RETURNED.
- StudentMetricsController: método myAssignments(...) con @PreAuthorize("hasAuthority('STUDENT')").
Nota de diseño: el workStatus proviene de CurrentSubmissionRow (preciso para SUBMITTED/RETURNED); una tarea sin entrega vigente reporta NOT_SUBMITTED con submission/veredicto nulos, aunque attempts puede ser > 0 si hubo entregas retiradas/reemplazadas (M7 cuenta todas). Consistente con el resumen S1.
Efectos secundarios: ninguno sobre las métricas docentes; solo superficie de lectura nueva.
Pruebas nuevas (StudentMetricsControllerIntegrationTest, +3): desglose del alumno con entrega (workStatus SUBMITTED, verdict AC, time/memory, grade 95/RETURNED); alumno sin entrega (fila vacía, grade null, attempts 0); calificación en borrador oculta; y 403 para no inscrito en ambos endpoints.
* docs(metrics): document student-facing self metrics
---------
Co-authored-by: JohannTF <trejofloresjohanndaniel@gmail.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved access, ownership, auditing, retry, validation-status, navigation, feature-boundary, and documentation issues require fixes.
30 open issues
And 10 more that still need to be addressed.
Review effort: Balanced
…onversion in compound assignment' Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
One or more issues must be addressed before approval.
31 open issues
And 11 more that still need to be addressed.
Review effort: Balanced
Comment on lines
+64
to
+65
| webSocketHandler.queueTask(taskId, requester.getId(), | ||
| () -> selfProvider.getObject().processAsync(csvData, taskId)); |
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved critical issues allow CSV registration after permission revocation, expose WebSocket tickets in logs, and let stale password-change responses restore or replace sessions.
16 open issues
22 resolved since last review
And 2 more resolved.
Review effort: Balanced
Comment on lines
+64
to
+65
| webSocketHandler.queueTask(taskId, requester.getId(), | ||
| () -> selfProvider.getObject().processAsync(csvData, taskId)); |
| logging.level.org.hibernate.orm.jdbc.bind=WARN | ||
|
|
||
| # Log Spring MVC requests and completion status to the application console. | ||
| logging.level.org.springframework.web.servlet.DispatcherServlet=DEBUG |
Comment on lines
+35
to
+38
| async updatePassword(currentPassword: string, newPassword: string) { | ||
| const response = await authApi.updatePassword(currentPassword, newPassword, getAuthToken()); | ||
| setAuthToken(response.data.token); | ||
| return response; |
Comment on lines
+17
to
+22
| const raw = window.localStorage.getItem(draftKey(userId, assignmentId)); | ||
| if (!raw) return null; | ||
| const value: unknown = JSON.parse(raw); | ||
| if (!value || typeof value !== "object") return null; | ||
| const draft = value as Partial<CodeDraft>; | ||
| if (typeof draft.language !== "string" || !draft.code || typeof draft.code !== "object") return null; |
| @@ -1,22 +1,4 @@ | |||
| import { API_BASE_URL } from "~/core/config/env"; | |||
| import { getAuthToken } from "~/core/storage/token.storage"; | |||
| import { AuthService } from "~/features/auth/services/auth.service"; | |||
| {/* Subtitle */} | ||
| <p className="text-lg lg:text-xl text-gray-600 dark:text-gray-400 max-w-xl mx-auto lg:mx-0"> | ||
| Reduce your grading time with autograded assignments, designed to engage students and provide instant feedback. | ||
| Reduce your grading time, this plaform was designed to engage students and provide instant feedback. |
Comment on lines
+47
to
+48
| - `postgresAssistantTest` checks assistant concurrency and development-schema indexes/constraints against an explicitly configured disposable PostgreSQL database. `liveAssistantTest` is an opt-in synthetic Gemini smoke, excluded from normal CI. See `docs/AI_ASSISTANT_ROLLOUT.md`. | ||
| - Contract and PostgreSQL development schema checklist live in `docs/AI_ASSISTANT_STAGE_0_CONTRACT.md` and `docs/AI_ASSISTANT_DEV_SCHEMA.sql`. |
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved critical issues expose WebSocket bearer tickets in logs, allow duplicate CSV import execution, and report successful sandbox setup despite image-tagging failures.
18 open issues
Review effort: Balanced
|
|
||
| while read -r image; do | ||
| if docker pull --quiet "$registry/sandbox/$image"; then | ||
| docker tag "$registry/sandbox/$image" "$image" |
| COPY --from=build /workspace/build/libs/*-SNAPSHOT.jar app.jar | ||
| # Entities store LocalDateTime and the browser reads those values as local time. | ||
| ENV TZ=America/Mexico_City | ||
| USER 10001 |
…n menu - Replace the fixed icon rail with a hamburger drawer below 640px for the student, teacher and admin shells; one nav list feeds both the rail and the drawer, and the breadcrumb collapses to the current page on phones. - Student dashboard: stack the groups/submissions aside under the main column below lg instead of squeezing it to 48px. - Workspace header: keep Run sample and Resubmit on screen at tablet width. - Fix horizontal overflow on the teacher dashboard, CSV upload, join code inputs and the reschedule date fields. - Loosen assignment and grade rows and the group detail actions on phones.
…ng hero - Extract the "How it works" hexagon pattern into a shared HexGridBackground and use it instead of the square grid on the landing hero and the password reset panels. - Add a blinking editor cursor after the last line of the hero code sample (static when reduced motion is preferred).
- New shared AuthSidePanel for the brand panel: eyebrow, headline, code card and feature list, with facts that match the backend (15-minute single-use reset link, 3 requests / 5 min, Java/Python/C/C++). - Restyle the sign-in form: "Welcome to CodeHive", envelope and prompt icons, "Forgot?" next to the password label, Continue button and a short Terms/Privacy note. - Remove the "Remember me for 30 days" checkbox, which was never sent to the backend. - Recovery confirmation: replace the incorrect "same browser session" notice and the dead support link with accurate guidance. - Add a `short` variant (max-height 820px) so the brand panels fit laptop-height windows instead of cutting off their footer.
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
A delayed password-change response can restore authentication after logout or overwrite a newly signed-in account because token and user updates are not guarded by an originating-session check.
18 open issues
Review effort: Balanced
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
Unresolved critical issues leak WebSocket credentials into logs, allow delayed password-change responses to overwrite newer sessions, and report success when required sandbox image tagging fails.
18 open issues
Review effort: Balanced
JohannTF
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds an educational AI assistant for students, an AI policy per assignment, and AI usage analytics for students, group owners and administrators. It also secures the CSV import progress socket, reworks the student workspace and teacher analytics, and fixes Java timeouts being reported as memory errors.
Fixes: no linked issue.
Reviewing the diff. GitHub lists 79 commits, but 53 of them already reached
mainthrough the squash of #89. The changes in this PR come from the other 26, starting atf1df115.graphify-out/accounts for 3.2 million of the 3.25 million added lines. Without it, the diff is 292 files, +16,561 / -2,120:AI assistant
/api/assignments/{assignmentId}/assistant: availability,POST /interactions(10 requests per minute) and conversation history.educational-assistant-v4), restricted by the assignment's assistance level.clientRequestIdwith the same payload creates no new interaction and charges no extra quota. Interrupted requests can be recovered (RF-11).google-genai1.76.0, default modelgemini-3.5-flash-lite. Spring and SDK retries are disabled, and provider calls are capped per minute.AssistantTextPurgeService).AI policy per assignment
Teachers set availability, a request limit (1 to 10 when enabled, 0 when disabled) and a level (
CONCEPTUAL_ONLY,EXPLANATIONS_AND_GUIDING,EXPLANATIONS_GUIDING_AND_SNIPPETS) when creating, cloning or editing an assignment. Existing assignments usePUT /api/assignments/{id}/ai-policy.AI usage analytics
/api/assistant-usage/me.../api/groups/{groupId}/assistant-usage...,/api/assignments/{assignmentId}/assistant-usage...,/api/assistant-usage/owned-groups/api/admin/assistant-usage...,/api/admin/users/{userId}/assistant-usage...ADMINandCHECK_ANALYTICS; per-user views also needVIEW_USERSModel calls are recorded in
assistant_model_callswithout prompts, context, code, HTTP bodies or generated text. This PR also addsGET /api/groups/{groupId}/metrics/students/{studentId}/assignments.Authentication and CSV import
POST /api/auth/websocket-ticketissues a single-use ticket, valid for 60 seconds and bound to the user, which the/ws/csv-progresshandshake requires.PUT /api/auth/me/passwordrevokes existing JWTs and returns a replacement session.Frontend
prismjs./admin/ai-usage./privacyand/termspages.Worker
java -Xrs Main, so SIGTERM fromtimeoutends the JVM directly. Before, the JVM signal handler could fail at the PID limit and escalate to SIGKILL (137), which was reported as MLE instead of TLE.docker execfailed intermittently on the deployed workers becauseruncalso runs inside the container's limit, which produced false RTE results with exit code 128.Configuration and documentation
docker-compose.yamlmoves MinIO to Chainguard images.DispatcherServletlogs atDEBUG, and the Tomcat access log is written to${user.dir}/logs.docs/ai-assistant/cover requirements, business rules, sequence diagrams, usage implementation and test records.llms/is updated.Google Cloud deployment
.dockerignorefiles for the backend and the worker,firebase.jsonfor the frontend, and.gcloudignorefor Cloud Build.deploy/gcp/: Cloud Build configuration, image build script, queue metric publisher and VM startup scripts. They contain no secrets or project identifiers; those values come from instance metadata and Secret Manager at startup.MINIO_REGIONlets the existing storage client work with Cloud Storage. Local MinIO behaves as before when it is not set.Type of Change
Breaking for API clients:
PUT /api/auth/me/passwordreturnsAuthResponseindatainstead ofnull, and previous JWTs stop working./ws/csv-progressrequires aticketquery parameter, and CSV imports do not start until the owner subscribes.How Has This Been Tested?
056a7d1./gradlew test(H2)The commits that follow
056a7d1add packaging files, the optionalMINIO_REGIONsetting, the new C and C++ PID limit and the frontend layout changes. At732af02, every CI job passed again except the CodeQL gate.Not covered:
postgresAssistantTestandliveAssistantTestare excluded from./gradlew testand have no recorded run.docs/ai-assistant/AI-TEST.mdrecords prompt-injection attempts and responses. TheMAN-*cases inAI_ASSISTANT_TESTS.md,AI_REQUEST_RETRY_EVIDENCE.mdandCH4_RNF_EVIDENCIAS.mdare guides with no recorded results.Test Configuration:
docker-compose.yaml; automated suites use in-memory H2Checklist
assistant-usage/api.tsandAdminAiUsagePage.tsximport other features' internals, whichCLAUDE.mddoes not allow.Test Coverage
Backend JaCoCo report at
056a7d1. Worker and frontend coverage are not reported.AssistantUsageRepository3.35%,AdminAssistantUsageController4.35%,WebSocketTicketHandshakeInterceptor16.22%,OwnerAssistantUsageController29.24%.Screenshots (if applicable)
None attached.
Additional Notes
Merge blocker: CodeQL
CodeQL reports one new high-severity alert (#3), "Clear text storage of sensitive information", at
codehive-frontend/app/core/storage/token.storage.ts:4. Thecode_scanningrule onmainblocks the merge while it stays open. It is a false positive: the stored value isresponse.data.token, the JWT returned byupdatePassword, not the password. Login stores its token through the same function.Alert #1 (
java/spring-disabled-csrf-protection) already exists onmainand is not part of this gate.Recovered work from
mainMerge commit
c00dbb9resolved overlaps in favor of this branch. Because #89 was a squash, Git also treated later work frombackup/no-student-statsas overlapping, and merging at that point would have removed it frommain. Commit056a7d1mergesbackup/no-student-statsfrom the real fork point (5354b39), which recovers:pendingUpdate).CREATE_GROUPis regained, deleted groups visible to their owner, and guarded restoration.CREATE_GROUP(GroupManagementRoute,ManagedGroupsSection) and role protection on/dashboard.GET /api/submissions/mine/{submissionId}/source.ActionMenu, archived groups in the gradebook, the assignment status drawer and list context, the clickable admin row, and role-aware enrollment.Where both sides implemented the same thing:
Assignment.setExamples@OrderByfrommaincode-drafts.tsanduseCodeDraft, adds delivered-code restore frommain, and removes the supersededcode-draft.tsandlanguage-switch.tsmain; the backend keeps its restore endpointsActionMenufrommain, keeps the Analytics link, and leaves join-code rotation in the Share dialogRemoved tests compared with
main:admin/api/client.test.ts,admin/utils/permissions.test.tsandstudent/api/metrics.api.test.ts, deleted incbbfc46.code-draft.test.tsandlanguage-switch.test.tsgo away with their modules, andcode-drafts.test.tscovers the initial-code rules.Open review findings
Of the 8 active Copilot threads, the ones on
AssignmentDTO.java,GlobalExceptionHandler.javaandStudentSidebar.tsxreport behavior that056a7d1recovers. Still open in the code:assistant-usage/api.tsandAdminAiUsagePage.tsx.BackLinkfalling back incorrectly when the page is opened directly.They do not block the merge under the current rules.
Deployment notes
ASSISTANT_ENABLED=trueandASSISTANT_MODEL_PROVIDER=google-genai. Related settings:GEMINI_API_KEY,GEMINI_MODEL,ASSISTANT_MODEL_MAX_OUTPUT_TOKENS,ASSISTANT_MODEL_TEMPERATURE,ASSISTANT_MODEL_TIMEOUT_SECONDSandASSISTANT_PROVIDER_CALLS_PER_MINUTE.ddl-auto=updatecreates the new tables (assignment_ai_policies,assistant_conversations,assistant_interactions,assistant_model_calls), but not the partial indexes and checks indocs/ai-assistant/AI_USAGE_DEV_SCHEMA.sql, such asux_assistant_one_pending. Apply that script in each environment once the tables exist.Repository size
graphify-out/grows from 135 MB to 285 MB in the repository.