Archivo historico de la wiki de EGC

Contenido archivado y de solo lectura, importado de la wiki original en julio de 2026. Puede contener enlaces rotos y material obsoleto.

Autenticación - 17 18 - G2

'''

Resumen del trabajo

''' Nuestro trabajo consistirá en realizar el apartado de autenticación que consiste en dar acceso a los distintos usuarios validando su email y contraseña, permitiéndoles un espacio definido según su rol registrado.

Miembros

'''

Objetivo del subsistema

''' Nuestro trabajo consistirá en realizar el apartado de autenticación definido arriba, el objetivo es conseguir que cada rol tenga su espacio independiente sin interferir con el de los demás, tiene que dar la posibilidad de que un mismo usuario se pueda registrar como poniente y como asistente con una sola cuenta y que no haya conflictos entre estas. Además, a la hora de la autenticación el usuario deberá completar un captcha para poder obtener dicho acceso.

Tecnologías elegidas

Consideraciones

Gestión de la comunicación

La comunicación se realizará a través de un grupo de WhatsApp formado por los miembros del equipo de trabajo. Además, se realizarán reuniones tanto presenciales como telemáticas a través de Skype.

Gestión del trabajo

Para gestionar las tareas y el tiempo usaremos Toggl. Ambas herramientas conjuntas nos permiten repartir las tareas entre los miembros del equipo y contabilizar el tiempo real que cada uno invierte en ellas.

Gestión del código

Realizaremos la gestión del código a través de GitHub con el formato dado por el grupo de integración. Los commits tendrán el siguiente formato dado por el grupo de integración:

Título del commit: tipo: aquí ponemos el título
Cuerpo del commit: aquí describimos el commit.
Pie del commit: Closes #<número de la incidencia en GitHub>

A continuación se detalla un ejemplo:

Título del commit: fix: redirección errónea tras intentar 
un usuario autenticarse
Cuerpo del commit: Después de que el usuario intente autenticarse era redireccionado a una URL no existente. Ahora el usuario es redireccionado a su inicio de sesión.
Pie del commit: Closes #<número de la incidencia en GitHub>

Ejemplo en texto:

fix: redirección errónea tras intentar autenticarse

Después de que el usuario intentara autenticarse, este era redireccionado a una URL no existente. Ahora el usuario es redireccionado a su inicio de sesión.

Los tipos de commit son los siguientes:

Gestión de las incidencias

La gestión de las incidencias se realizará siguiendo el siguiente formato dado por el grupo de integración:

Título: <breve título sobre la incidencia>
Prioridad: a seleccionar entre distintos valores: urgentealtomediobajo.
Estadopendienteen cursofinalizado. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
Descripción: <descripción detallada del error>
   La descripción puede incluir imagenes o la salida emitida por el fallo.
Etiquetas: <etiquetas de GitHub para clasificar las incidencias>
   enhancement: propuesta de mejora
   bug: fallos encontrados en el sistema
   help wanted: incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
   question: (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

Procedimiento general para la gestión de incidencias

  1. Establecer a un miembro del equipo el rol de gestor de incidencias.
  2. Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
  3. El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en Proyectos de GitHub.

Gestión de las ramas

Rama_G2-AT.png

''' Gestionaremos el proyecto añadiéndo tantas ramas como personas trabajen en él, de esta manera las tareas se dividirán por persona. Esta gestión la hemos recogido de la proporcionada por el grupo de integración.

El coordinador de nuestro grupo, José Ángel, será el encargado de realizar los commit a la rama master.

APIs y datos que se usarán y devolverán

'''

Se va a utilizar la API del curso anterior, vamos a realizar un cambio de lenguaje a python y además haremos las modificaciones oportunas junto con las pautas dada por el equipo de integración. Como el ser obligatorio que aparezcan en las respuestas los parámetros result (Es un Boolean que devuelve el resultado de la operación) y msg (Es un String que devuelve el memnsaje de resultado o error)

Recurso

Descripción

Parámetros

Ejemplo de llamada

Respuesta

Ejemplo de respuesta

Petición HTTP

getUser

Obtiene un usuario del sistema, incluyendo sus datos.

  • user: Nombre del usuario

url/api/getUser/nombreusuario

JSON con el usuario pedido. Los datos del usuario son los siguientes: "username", "name", "surname", "email", "genre", "autonomous_community", "age" y "role".

   {
       "result" : true,
       "msg" : "Successfull",
       "username" : "tansalalv",
       "name" : "Tania",
       "surname" : "Salguero Álvarez",
       "email" : "mail@example.com",
       "genre" : "Femenino",
       "autonomous_community" : "Andalucía",
       "age" : "21",
       "role" : "ASISTENTE"
   }

GET

getRoleUser

Obtiene el rol del usuario que se le ofrece por parámetros.

  • user: nombre del usuario cuyo rol queremos obtener.

url/api/getRoleUser/nombreusuario

JSON con el campo "role" indicando el rol del usuario siendo las opciones: "ASISTENTE", "PONENTE", "AMBOS".

   {
       "result" : true,
       "msg" : "Successfull",
       "role" = "AMBOS"
   }

GET

getUsers

Obtiene todos los usuarios del sistema, incluyendo sus datos.

url/api/getUsers

JSON con un array con los datos de cada usuario. Los datos de cada usuario son los siguientes: "username", "name", "surname", "email", "genre", "autonomous_community", "age" y "role".

   [{
       "result" : true,
       "msg" : "Successfull",
       "username" : "josgarrod17",
       "name" : "Jose Carlos",
       "surname" : "García Rodríguez",
       "email" : "mail1@example.com",
       "genre" : "Masculino",
       "autonomous_community" : "Andalucía",
       "age" : "21",
       "role" : "ASISTENTE"
   },
   {
       "result" : true,
       "msg" : "Successfull",
       "username" : "josdomesp",
       "name" : "Jose Ángel",
       "surname" : "Domínguez Espinaco",
       "email" : "mail2@example.com",
       "genre" : "Masculino",
       "autonomous_community" : "Madrid",
       "age" : "21",
       "role" : "PONENTE"
   }]

GET

getUsersByRole

Obtiene todos los usuarios del sistema que tenga el role pasado por parámetros, incluyendo sus datos.

url/api/getUsersByRole/role

JSON con un array con los datos de cada usuario que tenga el role pasado. Los datos de cada usuario son los siguientes: "username", "name", "surname", "email", "genre", "autonomous_community", "age" y "role".

   [{
       "result" : true,
       "msg" : "Successfull",
       "username" : "josgarrod17",
       "name" : "Jose Carlos",
       "surname" : "García Rodríguez",
       "email" : "mail1@example.com",
       "genre" : "Masculino",
       "autonomous_community" : "Andalucía",
       "age" : "21",
       "role" : "PONENTE"
   },
   {
       "result" : true,
       "msg" : "Successfull",
       "username" : "josdomesp",
       "name" : "Jose Ángel",
       "surname" : "Domínguez Espinaco",
       "email" : "mail2@example.com",
       "genre" : "Masculino",
       "autonomous_community" : "Madrid",
       "age" : "21",
       "role" : "PONENTE"
   }]

GET

checkToken

Comprueba si un token es válido. Para ello, se obtiene el usuario correspondiente al token (indicado al comienzo del token), se genera el token del usuario y se comprueba si es igual que el pasado como parámetro.

  • token: token a validar.

url/api/checkToken/token

JSON con los campos msg = 'Successful' y result = 'True' si es válido, msg = 'Error' y result = 'False' si no es válido

   {
       "result" : true,
       "msg" : "Successfull"
   }

GET

checkTokenUser

Comprueba si un token es válido para un usuario. Para ello, se obtiene el usuario pasado como parámetro, se genera el token del usuario y se comprueba si es igual que el pasado como parámetro.

  • username: nombre del usuario cuyo token se va a comprobar.
  • token: token a validar.

url/api/checkTokenUser/username/token

JSON con los campos msg = 'Successful' y result = 'True' si es válido, msg = 'Error' y result = 'False' si no es válido

   {
       "result" : true,
       "msg" : "Successfull",
   }

GET

postUser

Se le pasa por parámetros los datos que el usuario ingresa para registrarse en el sistema, se comprueba si los datos son válidos y se guarda el usuario.

  • formulario de ingreso en el sistema

url/api/postUser

JSON con el result y msg donde se muestra que todo ha ido correctamente.

   {
       "result" : true,
       "msg" : "Successfull",
   }

POST

Enlaces

Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/95 GitHub: https://github.com/EGC-G2-Trabajo-1718/autenticacion

Vistas del subsistema

Enlace a GitHub del proyecto con las vistas: https://github.com/EGC-G2-Trabajo-1718/autenticacion/tree/damserfer/ProyectoEGC