Autenticación - 17 18 - G2
Contenido
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
- Jose Carlos García Rodríguez
- Jose Ángel Domínguez Espinaco
- Tania Salguero Álvarez
- Damián Serrano Fernández
- Lizseth Katherine Esquen Saavedra
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
- Subsistema: Autenticación
- Lenguaje/Herramienta: Plugin para Eclipse Neon.3 (4.6.3) de Python 2.7 y Django 1.5.12
- Sistema de gestión de bibliotecas: pip
- Bibliotecas: SQLite3
- Necesita Base de datos: Sí (SQLite3)
Consideraciones
- Se deben gestionar roles o permisos para permitir el acceso a los distintos subsistemas. Por ejemplo, permisos solo para votar, para organizar votaciones, gestionar censos, ...
- Debe permitir que los otros subsistemas puedan conocer si un usuario está autenticado
- Wiki de la asignatura referente al submodulo (año pasado): https://1984.lsi.us.es/wiki-egc/index.php/Autenticaci%C3%B3n_B_1617
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 Trello integrado con 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. Los commits tendrán el siguiente formato:
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>
Los tipos de commit son los siguientes:
- feat: Una nueva característica.
- fix: Se soluciono un bug.
- docs: Se realizaron cambios en la documentación.
- style: Se aplico formato, comas y puntos faltantes, etc; Sin cambios en el código.
- refactor: Refactorización del código en producción.
- test: Se añadieron pruebas, refactorización de pruebas; Sin cambios en el código.
- chore: Actualización de tareas de build, configuración del admin. de paquetes; Sin cambios en el código.
Gestión de las incidencias
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.
Recurso | Descripción | Parámetros | Ejemplo de llamada | Respuesta | Ejemplo de respuesta |
---|---|---|---|---|---|
getUser | Obtiene un usuario del sistema, incluyendo sus datos. |
|
url/api/index.php?method=getUser&user=nombreusuario | JSON con el usuario pedido. Los datos del usuario son los siguientes: "username", "name", "surname", "email", "genre", "autonomous_community", "age" y "role". |
{ "username" : "tansalalv", "name" : "Tania", "surname" : "Salguero Álvarez", "email" : "mail@example.com", "genre" : "Femenino", "autonomous_community" : "Andalucía", "age" : "21", "role" : "USUARIO" } |
getRoleUser | Obtiene el rol del usuario que se le ofrece por parámetros. |
|
url/api/index.php?method=getRoleUser&user=nombreusuario | JSON con el campo "role" indicando el rol del usuario siendo las opciones: "USUARIO", "CREADOR_VOTACIONES" y "ADMIN". |
{ "role" = "USUARIO" } |
getUsers | Obtiene todos los usuarios del sistema, incluyendo sus datos. | url/api/index.php?method=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". |
[{ "username" : "josgarrod17", "name" : "Jose Carlos", "surname" : "García Rodríguez", "email" : "mail1@example.com", "genre" : "Masculino", "autonomous_community" : "Andalucía", "age" : "21", "role" : "USUARIO" }, { "username" : "josdomesp", "name" : "Jose Ángel", "surname" : "Domínguez Espinaco", "email" : "mail2@example.com", "genre" : "Masculino", "autonomous_community" : "Madrid", "age" : "21", "role" : "CREADOR_VOTACIONES" }] | |
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. |
|
url/api/index.php?method=checkToken&token=nombreusuario%3A5ca38d5a73c0f04c4f7cc1c35acc7a47 | JSON con el campo "valid" indicando la validez del token (true/false). |
{ "valid"=true } |
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. |
|
url/api/index.php?method=checkTokenUser&user=nombreusuario&token=nombreusuario%3A5ca38d5a73c0f04c4f7cc1c35acc7a47 | JSON con el campo "valid" indicando la validez del token (true/false). |
{ "valid"=true } |
Plantillas HTML
Enlaces
Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/95 GitHub: https://github.com/EGC-G2-Trabajo-1718/autenticacion