Diferencia entre revisiones de «Autenticación B 1617»
(→API) |
(→API) |
||
| Línea 65: | Línea 65: | ||
"age" : "21", | "age" : "21", | ||
"role" : "USUARIO" | "role" : "USUARIO" | ||
| + | } | ||
| + | |- | ||
| + | | getRoleUser | ||
| + | | Obtiene el rol del usuario que se le ofrece por parámetros. | ||
| + | | | ||
| + | * user: nombre del usuario cuyo rol queremos obtener. | ||
| + | | JSON con el campo "role" indicando el rol del usuario siendo las opciones: "USUARIO", "CREADOR_VOTACIONES" y "ADMIN". | ||
| + | | | ||
| + | { | ||
| + | "role" = "USUARIO" | ||
} | } | ||
|- | |- | ||
| Línea 112: | Línea 122: | ||
{ | { | ||
"valid"=true | "valid"=true | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
} | } | ||
|} | |} | ||
Revisión del 21:04 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 peticiones tendrán el siguiente formato, siendo todas de tipo GET:
http://[host]/auth/api/[recurso]?param1=value1¶m2=value2...
[host] hace referencia al host en el que se encuentre el sistema (localhost)
[recurso] hace referencia al nombre del recurso de la API.
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
