refactor(auth): consolidación de AuthService, seguridad en vinculación OAuth y blindaje de entorno - #71
Merged
Conversation
…unt linking confirmation Cambio fusionado que cubre tres rondas de trabajo sobre el mismo conjunto de archivos, declaradas explicitamente porque no admiten division limpia por hunks sin riesgo de dejar un estado intermedio no verificado: - Se extrae AuthService desde auth_bp.py, moviendo toda la logica de negocio de register, login, verificacion de correo y reset de password a la capa de servicio, alineando el archivo con el patron ya usado en ProfileService y PanoramaService. - Se elimina el endpoint GET /me duplicado en auth_bp.py; /profile/me queda como unica fuente de verdad. navbar-role.js migrado en consecuencia. - Se descompone google_login en AuthService.authenticate_with_google, separando verificacion de token, regla de email verificado y resolucion de cuenta. Se introduce GoogleLinkToken y el endpoint POST /google/confirm-link para exigir confirmacion explicita del usuario antes de vincular una cuenta de Google a una cuenta existente por coincidencia de email, en vez de vincular de forma silenciosa. - AppError extendido con el atributo detail para transportar el link_token en la respuesta de vinculacion pendiente. Co-authored-by: Oscar Soriano <neko.dev@outlook.com> Co-authored-by: Aylin Chavira <aylinchavirachv@gmail.com> Co-authored-by: Alejandro Balderrama <alejandro64.bp@gmail.com>
…orts Ronda 4 de esta rama: SECRET_KEY y JWT_SECRET_KEY ahora tienen guard condicionado a FLASK_ENV=production, siguiendo el mismo patron ya usado para RESEND_API_KEY y PIPELINE_TRIGGER_SECRET. Antes de este cambio, ambas claves podian arrancar la aplicacion en produccion usando su fallback inseguro hardcodeado sin ninguna validacion. Se eliminan ademas tres imports locales sin uso dentro de authenticate_with_google(), residuo de una version anterior del metodo antes de consolidar los imports de google.oauth2/google.auth a nivel de modulo (hallazgo pendiente de la Ronda 3, corregido aqui). Co-authored-by: Oscar Soriano <neko.dev@outlook.com> Co-authored-by: Aylin Chavira <aylinchavirachv@gmail.com> Co-authored-by: Alejandro Balderrama <alejandro64.bp@gmail.com>
|
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
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.
refactor/auth-service-consolidation
Descripción
Consolidamos la rama
refactor/auth-service-consolidation. En este ciclo de reestructuración profunda, estandarizamos la capa de autenticación extrayendo su lógica de negocio hacia un servicio dedicado, erradicamos la duplicidad de rutas públicas y fortalecimos significativamente la postura de seguridad del sistema resolviendo las deudas técnicas DT-23 y DT-25.Detalles técnicos que integramos:
refactor): Migramos toda la lógica de negocio (registro, inicio de sesión, verificación de correo y restablecimiento de contraseña) desdeauth_bp.pyhaciaAuthService, alineando el controlador con el patrón arquitectónico previamente establecido enProfileServiceyPanoramaService. Adicionalmente, eliminamos el endpoint duplicadoGET /meen el módulo de autenticación, consolidando/profile/mecomo la única fuente de verdad y actualizandonavbar-role.jsen consecuencia.google_loginseparando las responsabilidades (verificación de token, reglas de negocio y resolución de cuentas). Introdujimos el endpointPOST /google/confirm-linky el transporte medianteGoogleLinkToken. Esto elimina la vulnerabilidad de vinculación silenciosa automática: ahora el sistema exige confirmación explícita del usuario antes de asociar una identidad de Google a una cuenta local existente por coincidencia de correo electrónico. ExtendimosAppErrorcon el atributodetailpara transportar dicho token en la respuesta.FLASK_ENV=productionpara las variables críticasSECRET_KEYyJWT_SECRET_KEY. Esto erradica el riesgo de que la aplicación inicie en un entorno productivo utilizando valores de respaldo (fallbacks) inseguros insertados en el código. Paralelamente, depuramos el módulo eliminando importaciones locales huérfanas de librerías de Google.Tipo de cambio
Cómo probar
cd backend), activamos el entorno virtual.pytest -vFLASK_ENV=productionen nuestro entorno local y comentamos/eliminamos la variableSECRET_KEY. Al intentar levantar el servidor (flask run), el sistema debe abortar el arranque de inmediato.GoogleLinkToken.POST /google/confirm-linkenviando dicho token para finalizar exitosamente la asociación de la cuenta.Checklist
AuthService/mefue eliminada del controlador y del cliente web