[Autenticación] Los usuarios inicia sesión (valida sus credenciales) y obtiene permisos

Time
AssignCarlo Alfredo Pano FloresFrancisco Javier Huerta SilvaOOmar Alonso Del Río Peraltaa[email protected]
StatusCompleted
Created byCarlos Sanchez
Last edited byCarlos Sanchez
Last edited time
Created time

Requerimiento no funcional necesarios

https://www.notion.so/sanchezcarlosjr/Sistema-de-captura-del-Formato-911-3cb154ee123647f6a14a00630759c563#7450c430c50848159b17f0b338c6cfb8

Requerimiento funcional

Cuando el usuario ingresa un correo universitario y contraseña correctos entonces el sistema lista las "movilidades académicas de entrada".

Cuando el usuario ingresa un correo universitario y contraseña incorrectos entonces el sistema manda un mensaje de error “revise su correo y contraseña”.

Cuando el usuario termina la sesión entonces el sistema borra los datos de autenticación.

Consideraciones

El sistema de autenticación debe ser implementado usando la API proporcionada por la UABC.

Pero, el sistema de autorización es interno.

No se necesita crear una interfaz gráfica para el módulo de usuarios por lo que deben crearse desde la base de datos los roles, los usuarios y las asociaciones entre ellos.

Para la capa de presentación lo prioritario es el diseño de la interfaz.

Para la capa de negocio lo prioritario es mejorar el diseño del software, verificar la interacción de la API y crear el mecanismo de roles. Debe documentarse los roles, quienes son los usuarios y la asociación entre ellos (preguntar a Judith).

Capa de datos

Seeder (Semilla)

Mecanismo para crear usuarios desde un archivo CSV usando la API.

Use el entorno de playwright. 

POST /users
Authorization: Bearer TOKEN

[
 {
   "user": "EMAIL",
   "claims": ["1", "2"]
 }
]

Permisos

💡
Seguimos el estándar RBAC.

Cada usuario tiene una combinación de los siguientes claims:

login

income_academic_mobilities.create.*
income_academic_mobilities.edit.*
income_academic_mobilities.read.*
income_academic_mobilities.delete.*

outcome_academic_mobilities.create.*
outcome_academic_mobilities.edit.*
outcome_academic_mobilities.read.*
outcome_academic_mobilities.delete.*

income_exchange_student.create.*
income_exchange_student.edit.*
income_exchange_student.read.*
income_exchange_student.delete.*

outcome_exchange_student.create.*
outcome_exchange_student.edit.*
outcome_exchange_student.read.*
outcome_exchange_student.delete.*

agreements.create.*
agreements.edit.*
agreements.read.*
agreements.delete.*

users.create.*
users.edit.*
users.read.*
users.delete.*

De manera reductiva, se puede ver a un permiso como uno binario de escritura o lectura.

Roles

💡
Estos son implementados en la interfaz de usuario. NO en el modelo de dominio.
Esto da más flexibilidad.
tres niveles de usuario por campus
coordinacion general: rectoria
de los departamento: miguel alvarez
de las unidades academicas: coord vinculación y sub dirección
las unidades academicas son las que llenan la información para que lleguen limpios a rectoría

Usuarios

UserClaims
jluna*
Todos los miembros del equipo*
Aracely*

Los correos dependen por unidad académica.

El modelo utilizado es el siguiente:

erDiagram

User ||--|{ Claim : has

User {
	string email
}

Claim {
	string claim 
}

Capa de interfaz dominio-datos

graph LR


APIHandler --> Service
Service --> Database
Database --> Service
Service --> APIHandler

Capa de dominio

graph TD

subgraph User
/sessions/:token
/login
/logout
/users
end

users tiene los mismos métodos HTTP.

Consideraciones

Cuando el usuario quiere iniciar sesión entonces

sequenceDiagram
    Cliente->>Web Service: POST /sessions/login {'email': '([A-Z0-9])[email protected]', 'password': ''}
    Web Service-->>Cliente: HTTP 201 Created {'token': 'JWT'}
    Cliente->>Web Service: GET /sessions/:token/permissions
    Web Service-->>Cliente: HTTP 200 OK Role{'name': 'abc', 'permissions': [...]}

Cuando el usuario quiere terminar la sesión entonces

Con el protocolo JWT no es posible cerrar sesión.

Referencias

Capa de presentación web

Consideraciones

Mockups

Referencias