Diferencia entre revisiones de «Grupo Autenticación (2014-15)»
m (→Actas) |
(→Actas) |
||
(No se muestran 64 ediciones intermedias de 5 usuarios) | |||
Línea 1: | Línea 1: | ||
− | + | = Definición = | |
− | Un subsistema de [[Espacio_para_los_grupos_14-15|AGORA@US]] para autenticar usuarios y controlar quién puede votar y quién ya ha votado para evitar multiples votos de la misma persona. Este sistema tiene que ofrecer una | + | Un subsistema de [[Espacio_para_los_grupos_14-15|AGORA@US]] para autenticar usuarios y controlar quién puede votar y quién ya ha votado para evitar multiples votos de la misma persona. Este sistema tiene que ofrecer una API clara y sencilla para que otras partes del sistema puedan usarlo. Un sistema básico podría ser uno basado en un censo cerrado usando como identificador el correo electrónico. El sistema de autenticación tiene que ofrecer métodos para: |
− | |||
* Realizar una prueba de verificación de identidad | * Realizar una prueba de verificación de identidad | ||
− | * | + | * Autenticar usuarios |
+ | * Registrar usuarios | ||
+ | |||
+ | = Aspectos organizativos = | ||
== Miembros == | == Miembros == | ||
+ | |||
* [[Usuario:Danayaher|Daniel Ayala Hernández]]: Gestor de la configuración | * [[Usuario:Danayaher|Daniel Ayala Hernández]]: Gestor de la configuración | ||
* [[Usuario:Dandelea|Daniel de los Reyes Leal]]: Gestor de la configuración | * [[Usuario:Dandelea|Daniel de los Reyes Leal]]: Gestor de la configuración | ||
Línea 12: | Línea 15: | ||
* [[Usuario:Juarolsal|Juan Carlos Roldán Salvador]]: Gestor de la configuración | * [[Usuario:Juarolsal|Juan Carlos Roldán Salvador]]: Gestor de la configuración | ||
* [[Usuario:Alesanmed|Alejandro Sánchez Medina]]: Jefe de proyecto | * [[Usuario:Alesanmed|Alejandro Sánchez Medina]]: Jefe de proyecto | ||
− | * [[Usuario:Juacaslop|Juan Luis Casal López]]: Gestor de la configuración | + | * <strike>[[Usuario:Juacaslop|Juan Luis Casal López]]: Gestor de la configuración</strike> Este miembro del proyecto ha cancelado su matrícula en la asignatura |
− | == | + | == Diario de grupo == |
− | === | + | === Hojas de tiempo === |
+ | Debido a su extensión, la '''hoja de tiempos''' se encuentra en una sección aparte: | ||
− | + | * [[Hoja de tiempos grupo autenticación 2014-2015 | Hoja de tiempos del grupo Autenticación (2014-15)]]. | |
− | + | En ella se encuentran consideraciones relacionadas con '''la implicación de los miembros del grupo'''. | |
− | |||
− | === | + | === Actas === |
− | + | * [[Acta del taller de creación de grupos (Autenticación 2014-15)|Acta del taller de creación de grupos (29/09/2014)]] | |
+ | * [[Acta del taller de arquitectura de la aplicación (Autenticación 2014-15)|Acta del taller de arquitectura de la aplicación (01/10/2014)]] | ||
+ | * [[Acta reunión inicial de portavoces de grupos (Autenticación 2014-15)|Acta reunión inicial de portavoces de grupos (06/10/2014)]] | ||
+ | * [[Acta del taller de gestión de código I (Autenticación 2014-15)|Acta del taller de gestión de código I (06/10/2014)]] | ||
+ | * [[Acta del taller de gestión de código II (Autenticación 2014-15)|Acta del taller de gestión de código II (08/10/2014)]] | ||
+ | * [[Acta de la práctica 1 (Autenticación 2014-15)|Acta de la práctica 1 (15/10/2014)]] | ||
+ | * [[Acta de reunión de portavoces de grupos II (Autenticación 2014-15)|Acta de reunión de portavoces de grupos II (20/10/2014)]] | ||
+ | * [[Acta del taller de gestión de código III (Autenticación 2014-15)|Acta del taller de gestión de código III (24/10/2014)]] | ||
+ | * [[Acta de la práctica 2 (Autenticación 2014-15)|Acta de la práctica 2 (22/10/2014)]] | ||
+ | * [[Acta del taller de gestión de codigo III 27/10/14|Acta 2 del taller de gestión de código III (27/10/2014)]] | ||
+ | * [[Acta de la práctica 3 (Autenticación 2014-15)|Acta de la práctica 3 (30/10/2014)]] | ||
+ | * [[Acta de planificación de Jornada I (Autenticación 2014-15)|Acta de la planificación de Jornada I (03/11/2014)]] | ||
+ | * [[Acta de la práctica 4 (Autenticación 2014-15)|Acta de la práctica 4 (05/11/2014)]] | ||
+ | * [[Acta del taller de integración 10/11/14|Acta del taller de integración (10/11/2014)]] | ||
+ | * [[Acta de la práctica 5 (Autenticación 2014-15)|Acta de la práctica 5 (12/11/2014)]] | ||
+ | * [[Acta de la práctica 6 (Autenticación 2014-15)|Acta de la práctica 6 (19/11/2014)]] | ||
+ | * [[Acta taller de integraión 24/11/2014 (Autenticación 2014-15)|Acta taller de integración (24/11/2014)]] | ||
+ | * [[Acta de cambios en el equipo de trabajo (Autenticación 2014-15)|Acta de cambios en el equipo de trabajo (9/12/2014)]] | ||
+ | * [[Acta de discusión sobre políticas de depuración | Acta de discusión sobre políticas de depuración (11/12/2014)]] | ||
+ | * [[Acta de discusión sobre integración | Acta de discusión sobre integración (17/12/2014)]] | ||
+ | * [[Acta de negociación de la implicación | Acta de negociación sobre la implicación (17/01/2015)]] | ||
− | + | == Iteraciones == | |
− | + | Son susceptibles de entrar en esta categoría aquellos trabajos en clase que tengan un entregable. Para ver las actas de otros entregables, ver el [[#Diario de grupo|diario de grupo.]] | |
− | + | * [[Iteración del taller de gestión de código I (Autenticación 2014-15)|Iteración del taller de gestión de código I (06/10/2014)]] | |
+ | * [[Iteración del taller de gestión de código II (Autenticación 2014-15)|Iteración del taller de gestión de código II (08/10/2014)]] | ||
+ | * [[Iteración de la práctica 1 (Autenticación 2014-15)|Iteración de la práctica 1 (15/10/2014)]] | ||
+ | * [[Iteración del taller de gestión de código III (Autenticación 2014-15)|Iteración del taller de gestión de código III (27/10/2014)]] | ||
+ | * [[Iteración de propuesta de integración (Autenticación 2014-15)|Iteración de propuesta de integración (17/11/2014)]] | ||
− | + | == Repositorio de código == | |
− | |||
− | |||
− | + | Actualmente, el repositorio en el que se encuentra nuestro código es el [https://github.com/EGC-1415-Repositorio-compartido/repvoting repositorio compartido con los demas subsistemas]. Una versión estable se puede encontrar en la carpeta <code>auth</code> de la rama <code>master</code>, y una versión más actualizada en la misma carpeta, en la rama <code>auth</code>. El resto de ramas <code>auth_*</code> son ramas de desarrollo. | |
− | + | Antes de que existiera un repositorio común, usamos este repositorio [https://github.com/EGC-Autenticacion-14-15/EGC-Autenticacion-14-15 repositorio del Grupo de Autenticación]. | |
− | |||
− | |||
− | |||
− | == | + | == Gestión de la comunicación == |
− | + | Toda la comunicación se lleva a cabo presencialmente en horario de clase, y de forma remota mediante el uso de herramientas de mensajería instantánea (Telegram). | |
− | |||
− | + | El diario de grupo se mantiene en esta wiki, y las actas se van publicando como páginas individuales dentro del diario de grupo. | |
− | + | = Aspectos técnicos = | |
− | + | == Interfaz del sistema == | |
− | + | El sistema de autenticación se encargará de realizar la autenticación del usuario antes de que este acceda al resto de la aplicación. Para que quede constancia de su estado como autenticado, se almacenarán en su navegador 2 cookies: | |
+ | * Una con identificador "user", en la que se almacenará el nombre de usuario autenticado. | ||
+ | * Una con identificador "token", en la que se almacenará un token generado a partir de su nombre de usuario y contraseña. | ||
− | + | Siempre que se desee comprobar que el usuario accediendo a una funcionalidad está correctamente autenticado, se debe comprobar que el token almacenado en la cookie es el correcto. Para ello se ofrecen métodos en la API descrita a continuación: | |
− | + | === API === | |
− | |||
− | |||
− | |||
− | + | Las peticiones tendrán el siguiente formato, siendo todas de tipo '''GET''': | |
+ | http://[host]/auth/api/[recurso]?param1=value1¶m2=value2... | ||
− | + | <code>[host]</code> hace referencia al host en el que se encuentre el sistema (<code>localhost</code>) | |
− | + | <code>[recurso]</code> hace referencia al nombre del recurso de la API. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Están disponibles los siguientes: | |
− | |- | + | {| border="1" style="border-collapse:collapse" |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | + | ! Recurso | |
− | + | ! Descripción | |
− | + | ! Parámetros | |
− | + | ! Respuesta | |
− | + | ! Ejemplo de respuesta | |
− | |||
|- | |- | ||
− | | | + | | getUser |
− | | | + | | Obtiene un usuario del sistema, incluyendo sus datos. Este método solo puede ser usado por subsistemas locales (acceso mediante localhost). |
− | |||
− | |||
| | | | ||
− | * | + | * user: nombre del usuario |
− | | | + | | JSON con el usuario pedido. Los datos del usuario son los siguientes: "username", "password" y "email", "genre" y "autonomous_community". |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
| | | | ||
− | + | { | |
− | + | "username" : "johndoe", | |
+ | "password" : "foo_bar", | ||
+ | "email" : "mail@example.com", | ||
+ | "genre" : "Masculino", | ||
+ | "autonomous_community" : "Madrid", | ||
+ | "age" : "18" | ||
+ | } | ||
|- | |- | ||
− | | | + | | getUsers |
− | | | + | | Obtiene todos los usuarios del sistema, incluyendo sus datos. Este método solo puede ser usado por subsistemas locales (acceso mediante localhost). |
− | |||
− | |||
| | | | ||
− | + | | JSON con un array con los datos de cada usuario. Los datos de cada usuario son los siguientes: "username", "password" y "email", "genre" y "autonomous_community". | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
| | | | ||
− | + | [{ | |
+ | "username" : "johndoe", | ||
+ | "password" : "foo_bar", | ||
+ | "email" : "mail@example.com", | ||
+ | "genre" : "Masculino", | ||
+ | "autonomous_community" : "Madrid", | ||
+ | "age" : "18" | ||
+ | }, | ||
+ | { | ||
+ | "username" : "Marta", | ||
+ | "password" : "12345", | ||
+ | "email" : "mail2@example.com", | ||
+ | "genre" : "Femenino", | ||
+ | "autonomous_community" : "Madrid", | ||
+ | "age" : "26" | ||
+ | }] | ||
|- | |- | ||
− | | | + | | 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. |
− | + | | 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. |
− | | | + | | |
− | | | + | * user: nombre del usuario cuyo token se va a comprobar. |
+ | * token: token a validar. | ||
+ | | 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 | ||
+ | |||
+ | === Instalación del subsistema === | ||
+ | |||
+ | Se está trabajando en una máquina virtual que disponga de las 3 plataformas usadas por los equipos: XAMPP, Django y Spring MVC. | ||
+ | |||
+ | Mientras tanto, para la instalación del sistema los pasos a seguir son los siguientes: | ||
+ | |||
+ | # Instalar XAMPP con los módulos Apache y MySQL (que vienen instalados por defecto). La instalación es trivial en Windows, Linux y OS X. Se puede obtener [https://www.apachefriends.org/es/index.html aquí]. | ||
+ | # Borrar el contenido de la carpeta de proyectos. Habitualmente es <code>C:/xampp/hdtocs</code>. | ||
+ | # Introducir en la carpeta de proyectos una carpeta <code>auth</code> con el contenido de la carpeta <code>auth</code> que se encuentra en el [https://github.com/EGC-1415-Repositorio-compartido/repvoting repositorio compartido]. | ||
+ | # Si se van a instalar otros subsistemas en la misma máquina, saltar este paso: Con Apache y MySQL activados (en el Control Panel de XAMPP) entrar en <code>localhost/phpmyadmin</code> y crear un usuario llamado 'usuario' con la contraseña 'password'. Crear una base de datos con el nombre 'egcdb' y dar todos los privilegios al usuario creado anteriormente. | ||
+ | # Suponiendo que ya se encuentre en la base de datos un usuario llamado 'usuario', con una contraseña 'password', no será necesario (ni posible) iniciar MySQL desde XAMPP. | ||
+ | |||
+ | == Subsistemas relacionados == | ||
+ | |||
+ | * Cabina de votación: Deberá comprobar que sus usuarios estén logueados en la aplicación. | ||
+ | * Creación/administración de votaciones: Deberá comprobar que sus usuarios estén logueados en la aplicación. | ||
+ | * Deliberaciones: Deberá comprobar que sus usuarios estén logueados en la aplicación. | ||
+ | |||
+ | == Guía de integración == | ||
+ | |||
+ | En esta sección se detalla una guía de cómo integrar nuestro subsistema con los relacionados. En principio está dirigida a los miembros de nuestro grupo, pero puede ser usada por cualquier persona que tenga la máquina virtual que usamos nosotros. | ||
+ | La máquina tiene los proyectos necesarios importados en eclipse y funcionando. Además, se encuentra en la carpeta /home/egc, la carpeta cabina-integración, con los archivos necesarios para ejecutar dicho subsistema. Todo está actualizado el día 21/12/2014 a las 16:00. | ||
− | * | + | * 1. Encender la máquina e iniciar eclipse desde su carpeta /home/egc/eclipse. |
− | * | + | * 2. En el apartado Servers (en el panel derecho) pulsar con botón derecho y elegir la opción '''Add and Remove...'' y verificar que están los 3 proyectos en el cuadro derecho. Si alguno no estuviera, añadirlo. |
− | * | + | * 3. Iniciar el servicio de apache desde el terminal con el comando sudo service apache2 start. La contraseña del usuario es egc. |
− | * | + | * 4. Iniciar el servidor de Tomcat desde eclipse, seleccionándolo en el panel derecho y pulsando el icono verde con el símbolo de play. |
− | * | + | * 5. Iniciar la aplicación de cabina desde el terminar mediante el comando sudo /home/egc/cabina-integracion/run.sh o mediante las instrucciones que se encuentran dentro de la máquina. |
− | + | * 6. Para probar que se ha integrado correctamente con cada subsistema, realizar lo siguiente: | |
− | * | + | ** Deliberaciones: se accede a la ruta de la aplicación y se selecciona la opción '''Login from authenticate'''. En el formulario que aparece, introducir el nombre de usuario en el primer campo '''user''' y la contraseña en el campo '''password'''. Si muestra acciones disponibles en el menú superior con el nombre de usuario introducido, se ha identificado y, por lo tanto, integrado correctamente. |
− | * | + | ** Creación y administración de censos: se accede a la aplicación de autenticación, la cual se encuentra en '''localhost/auth''', se introducen los datos de conexión y se envían. Si el login es correcto, deberá redirigir a la aplicación de creación y administración de censos y, al seleccionar las distintas opciones del menú '''no''' saldrá una página con el texto '''Panic'''. Si el resultado es lo esperado, significa que la integración se ha realizado con éxito. |
− | + | ** Creación y administración de votaciones: se accede a la aplicación y, si en la pantalla principal no se muestra opción alguna, sino solo texto, se deberá acceder a la aplicación de autenticación en '''localhost/auth''', identificarse y volver a acceder a la aplicación de creación y administración de votaciones. Si muestra opciones en la pantalla principal (si no es el caso, probar a refrescar la página con Ctrl+F5), la primera parte de la integración será correcta. Ahora se deberá acceder a la pantalla de creación de votaciones, introducir datos correctos y pulsar '''Enviar'''. La aplicación redirigirá a una vista con la lista de votaciones, donde deberá aparecer la que acabamos de crear. | |
− | * | ||
− |
Revisión actual del 17:51 20 ene 2015
Definición
Un subsistema de AGORA@US para autenticar usuarios y controlar quién puede votar y quién ya ha votado para evitar multiples votos de la misma persona. Este sistema tiene que ofrecer una API clara y sencilla para que otras partes del sistema puedan usarlo. Un sistema básico podría ser uno basado en un censo cerrado usando como identificador el correo electrónico. El sistema de autenticación tiene que ofrecer métodos para:
- Realizar una prueba de verificación de identidad
- Autenticar usuarios
- Registrar usuarios
Aspectos organizativos
Miembros
- Daniel Ayala Hernández: Gestor de la configuración
- Daniel de los Reyes Leal: Gestor de la configuración
- Fidel Mazo Delgado: Gestor de la configuración
- Juan Carlos Roldán Salvador: Gestor de la configuración
- Alejandro Sánchez Medina: Jefe de proyecto
-
Juan Luis Casal López: Gestor de la configuraciónEste miembro del proyecto ha cancelado su matrícula en la asignatura
Diario de grupo
Hojas de tiempo
Debido a su extensión, la hoja de tiempos se encuentra en una sección aparte:
En ella se encuentran consideraciones relacionadas con la implicación de los miembros del grupo.
Actas
- Acta del taller de creación de grupos (29/09/2014)
- Acta del taller de arquitectura de la aplicación (01/10/2014)
- Acta reunión inicial de portavoces de grupos (06/10/2014)
- Acta del taller de gestión de código I (06/10/2014)
- Acta del taller de gestión de código II (08/10/2014)
- Acta de la práctica 1 (15/10/2014)
- Acta de reunión de portavoces de grupos II (20/10/2014)
- Acta del taller de gestión de código III (24/10/2014)
- Acta de la práctica 2 (22/10/2014)
- Acta 2 del taller de gestión de código III (27/10/2014)
- Acta de la práctica 3 (30/10/2014)
- Acta de la planificación de Jornada I (03/11/2014)
- Acta de la práctica 4 (05/11/2014)
- Acta del taller de integración (10/11/2014)
- Acta de la práctica 5 (12/11/2014)
- Acta de la práctica 6 (19/11/2014)
- Acta taller de integración (24/11/2014)
- Acta de cambios en el equipo de trabajo (9/12/2014)
- Acta de discusión sobre políticas de depuración (11/12/2014)
- Acta de discusión sobre integración (17/12/2014)
- Acta de negociación sobre la implicación (17/01/2015)
Iteraciones
Son susceptibles de entrar en esta categoría aquellos trabajos en clase que tengan un entregable. Para ver las actas de otros entregables, ver el diario de grupo.
- Iteración del taller de gestión de código I (06/10/2014)
- Iteración del taller de gestión de código II (08/10/2014)
- Iteración de la práctica 1 (15/10/2014)
- Iteración del taller de gestión de código III (27/10/2014)
- Iteración de propuesta de integración (17/11/2014)
Repositorio de código
Actualmente, el repositorio en el que se encuentra nuestro código es el repositorio compartido con los demas subsistemas. Una versión estable se puede encontrar en la carpeta auth
de la rama master
, y una versión más actualizada en la misma carpeta, en la rama auth
. El resto de ramas auth_*
son ramas de desarrollo.
Antes de que existiera un repositorio común, usamos este repositorio repositorio del Grupo de Autenticación.
Gestión de la comunicación
Toda la comunicación se lleva a cabo presencialmente en horario de clase, y de forma remota mediante el uso de herramientas de mensajería instantánea (Telegram).
El diario de grupo se mantiene en esta wiki, y las actas se van publicando como páginas individuales dentro del diario de grupo.
Aspectos técnicos
Interfaz del sistema
El sistema de autenticación se encargará de realizar la autenticación del usuario antes de que este acceda al resto de la aplicación. Para que quede constancia de su estado como autenticado, se almacenarán en su navegador 2 cookies:
- Una con identificador "user", en la que se almacenará el nombre de usuario autenticado.
- Una con identificador "token", en la que se almacenará un token generado a partir de su nombre de usuario y contraseña.
Siempre que se desee comprobar que el usuario accediendo a una funcionalidad está correctamente autenticado, se debe comprobar que el token almacenado en la cookie es el correcto. Para ello se ofrecen métodos en la API descrita a continuación:
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. Este método solo puede ser usado por subsistemas locales (acceso mediante localhost). |
|
JSON con el usuario pedido. Los datos del usuario son los siguientes: "username", "password" y "email", "genre" y "autonomous_community". |
{ "username" : "johndoe", "password" : "foo_bar", "email" : "mail@example.com", "genre" : "Masculino", "autonomous_community" : "Madrid", "age" : "18" } |
getUsers | Obtiene todos los usuarios del sistema, incluyendo sus datos. Este método solo puede ser usado por subsistemas locales (acceso mediante localhost). | JSON con un array con los datos de cada usuario. Los datos de cada usuario son los siguientes: "username", "password" y "email", "genre" y "autonomous_community". |
[{ "username" : "johndoe", "password" : "foo_bar", "email" : "mail@example.com", "genre" : "Masculino", "autonomous_community" : "Madrid", "age" : "18" }, { "username" : "Marta", "password" : "12345", "email" : "mail2@example.com", "genre" : "Femenino", "autonomous_community" : "Madrid", "age" : "26" }] | |
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
Instalación del subsistema
Se está trabajando en una máquina virtual que disponga de las 3 plataformas usadas por los equipos: XAMPP, Django y Spring MVC.
Mientras tanto, para la instalación del sistema los pasos a seguir son los siguientes:
- Instalar XAMPP con los módulos Apache y MySQL (que vienen instalados por defecto). La instalación es trivial en Windows, Linux y OS X. Se puede obtener aquí.
- Borrar el contenido de la carpeta de proyectos. Habitualmente es
C:/xampp/hdtocs
. - Introducir en la carpeta de proyectos una carpeta
auth
con el contenido de la carpetaauth
que se encuentra en el repositorio compartido. - Si se van a instalar otros subsistemas en la misma máquina, saltar este paso: Con Apache y MySQL activados (en el Control Panel de XAMPP) entrar en
localhost/phpmyadmin
y crear un usuario llamado 'usuario' con la contraseña 'password'. Crear una base de datos con el nombre 'egcdb' y dar todos los privilegios al usuario creado anteriormente. - Suponiendo que ya se encuentre en la base de datos un usuario llamado 'usuario', con una contraseña 'password', no será necesario (ni posible) iniciar MySQL desde XAMPP.
Subsistemas relacionados
- Cabina de votación: Deberá comprobar que sus usuarios estén logueados en la aplicación.
- Creación/administración de votaciones: Deberá comprobar que sus usuarios estén logueados en la aplicación.
- Deliberaciones: Deberá comprobar que sus usuarios estén logueados en la aplicación.
Guía de integración
En esta sección se detalla una guía de cómo integrar nuestro subsistema con los relacionados. En principio está dirigida a los miembros de nuestro grupo, pero puede ser usada por cualquier persona que tenga la máquina virtual que usamos nosotros. La máquina tiene los proyectos necesarios importados en eclipse y funcionando. Además, se encuentra en la carpeta /home/egc, la carpeta cabina-integración, con los archivos necesarios para ejecutar dicho subsistema. Todo está actualizado el día 21/12/2014 a las 16:00.
- 1. Encender la máquina e iniciar eclipse desde su carpeta /home/egc/eclipse.
- 2. En el apartado Servers (en el panel derecho) pulsar con botón derecho y elegir la opción 'Add and Remove... y verificar que están los 3 proyectos en el cuadro derecho. Si alguno no estuviera, añadirlo.
- 3. Iniciar el servicio de apache desde el terminal con el comando sudo service apache2 start. La contraseña del usuario es egc.
- 4. Iniciar el servidor de Tomcat desde eclipse, seleccionándolo en el panel derecho y pulsando el icono verde con el símbolo de play.
- 5. Iniciar la aplicación de cabina desde el terminar mediante el comando sudo /home/egc/cabina-integracion/run.sh o mediante las instrucciones que se encuentran dentro de la máquina.
- 6. Para probar que se ha integrado correctamente con cada subsistema, realizar lo siguiente:
- Deliberaciones: se accede a la ruta de la aplicación y se selecciona la opción Login from authenticate. En el formulario que aparece, introducir el nombre de usuario en el primer campo user y la contraseña en el campo password. Si muestra acciones disponibles en el menú superior con el nombre de usuario introducido, se ha identificado y, por lo tanto, integrado correctamente.
- Creación y administración de censos: se accede a la aplicación de autenticación, la cual se encuentra en localhost/auth, se introducen los datos de conexión y se envían. Si el login es correcto, deberá redirigir a la aplicación de creación y administración de censos y, al seleccionar las distintas opciones del menú no saldrá una página con el texto Panic. Si el resultado es lo esperado, significa que la integración se ha realizado con éxito.
- Creación y administración de votaciones: se accede a la aplicación y, si en la pantalla principal no se muestra opción alguna, sino solo texto, se deberá acceder a la aplicación de autenticación en localhost/auth, identificarse y volver a acceder a la aplicación de creación y administración de votaciones. Si muestra opciones en la pantalla principal (si no es el caso, probar a refrescar la página con Ctrl+F5), la primera parte de la integración será correcta. Ahora se deberá acceder a la pantalla de creación de votaciones, introducir datos correctos y pulsar Enviar. La aplicación redirigirá a una vista con la lista de votaciones, donde deberá aparecer la que acabamos de crear.