Diferencia entre revisiones de «Autenticación B 1617»
(→API) |
(→API) |
||
| Línea 34: | Línea 34: | ||
Las llamadas a la API seguiran el siguiente patrón: | Las llamadas a la API seguiran el siguiente patrón: | ||
| − | + | .../auth/api/[recurso]?param1=value1¶m2=value2... | |
donde "recurso" será el nombre del recurso que se quiere utilizar y los "paramX" será el nombre del parámetro a introducir. | donde "recurso" será el nombre del recurso que se quiere utilizar y los "paramX" será el nombre del parámetro a introducir. | ||
Revisión del 22:15 9 ene 2017
Contenido
Descripción
Creación de un subsistema de AGORA@US encargado principalmente de permitir acceder a la plataforma mediante la autenticación del usuario. La autenticación consiste en verificar el correcto acceso de los usuarios a la plataforma mediante las distintas opciones que se proporcionan. Este subsistema tiene que ofrecer una api clara y sencilla para que otras partes del sistema puedan usarlo.
Miembros
- Manuel Caballero Clá: Software Developer
- Carlos Campos Cuesta: Software Developer
- Alejandro Rodriguez Romero: Project Manager
- Carlos Ruiz Vargas: Software Developer
- Rubén Suárez Almenta: Software Developer
Diario de Grupo
Actas
- Acta de reunión de grupo (02/11/2016)
- Acta de reunión de grupo (23/11/2016)
- Acta de reunión de grupo (14/12/2016)
- Acta de reunión de grupo (21/12/2016)
Gestión de incidencias
Las incidencias serán gestionadas mediante el apartado "Issues" que nos proporciona GitHub. Serán analizadas y clasificadas en distintos niveles de gravedad:
- Grave: Impide el correcto uso de la aplicación de forma crítica y necesita ser solucionado cuanto antes.
- Medio: El funcionamiento del sistema se ve afectado, aunque no de forma severa.
- Leve: Permite el uso de la aplicación, aunque no de forma correcta.
Tras su análisis y clasificación serán asignadas a un miembro del equipo de trabajo para su correción. Una vez corregido el problema será revisado y verificado por un miembro diferente del grupo. Si la incidencia ha sido solucionada, se procederá a su cierre y se archivará.
API
Las llamadas a la API seguiran el siguiente patrón:
.../auth/api/[recurso]?param1=value1¶m2=value2...
donde "recurso" será el nombre del recurso que se quiere utilizar y los "paramX" será el nombre del parámetro a introducir.
Están disponibles los siguientes:
| Recurso | Descripción | Parámetros | Respuesta | Ejemplo de respuesta |
|---|---|---|---|---|
| getUser | Obtiene un usuario del sistema, incluyendo sus datos. |
|
JSON con el usuario pedido. Los datos del usuario son los siguientes: "username", "name", "surname", "email", "genre", "autonomous_community", "age" y "role". |
{
"username" : "carruivar",
"name" : "Carlos",
"surname" : "Ruiz Vargas",
"email" : "mail@example.com",
"genre" : "Masculino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}
|
| getRoleUser | Obtiene el rol del usuario que se le ofrece por parámetros. |
|
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. | 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" : "carruivar",
"name" : "Carlos",
"surname" : "Ruiz Vargas",
"email" : "mail@example.com",
"genre" : "Masculino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
},
{
"username" : "alerodrom",
"name" : "Alejandro",
"surname" : "Rodriguez Romero",
"email" : "mail2@example.com",
"genre" : "Masculino",
"autonomous_community" : "Madrid",
"age" : "22",
"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. |
|
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. |
|
JSON con el campo "valid" indicando la validez del token (true/false). |
{
"valid"=true
}
|
Si en una petición no se pasan unos parámetros correctos (métodos que no existen o falta de parámetros necesarios) se devolverá un error de código 400 con el siguiente mensaje:
Bad Request. This method doesn't exist or the necessary paramenters weren't provided
