Codacy's code quality: Codacy's coverage: Travis CI status:

El objetivo de este proyecto es implementar una plataforma de voto electrónico seguro, que cumpla una serie de garantías básicas, como la anonimicidad y el secreto del voto.

Se trata de un proyecto educativo, pensado para el estudio de sistemas de votación, por lo que prima la simplicidad por encima de la eficiencia cuando sea posible. Por lo tanto se asumen algunas carencias para permitir que sea entendible y extensible.

El proyecto se divide en subsistemas, los cuales estarán desacoplados entre ellos. Para conseguir esto, los subsistemas se conectarán entre si mediante API y necesitamos un proyecto base donde configurar las ruts de estas API.

Este proyecto Django estará dividido en apps (subsistemas y proyecto base), donde cualquier app podrá ser reemplazada individualmente.

Para ofrecer un punto de entrada conocido para todos los subsistemas existe el llamado gateway que no es más que una ruta disponible que redirigirá todas las peticiones al subsistema correspondiente, de tal forma que cualquier cliente que use la API no tiene por qué saber en qué servidor está desplegado cada subsistema.

La ruta se compone de:

http://DOMINIO/gateway/SUBSISTEMA/RUTA/EN/EL/SUBSISTEMA

Por ejemplo para acceder al subsistema de autenticación y hacer la petición al endpoint de /authentication/login/ deberíamos hacer la petición a la siguiente ruta:

http://DOMINIO/gateway/authentication/login/

Otro ejemplo sería para obtener una votación por id:

http://DOMINIO/gateway/voting/?id=1

A nivel interno, el módulo mods ofrece esta funcionalidad, pero el gateway es útil para hacer uso desde peticiones de cliente, por ejemplo en el javascript de la cabina de votación o la visualización de resultados, y también para módulos externos que no sean aplicaciones django.

Para configurar el proyecto, podremos crearnos un fichero local_settings.py basado en el local_settings.example.py, donde podremos configurar la ruta de nuestras apps o escoger que módulos ejecutar.

Una vez hecho esto, será necesario instalar las dependencias del proyecto, las cuales están en el fichero requirements.txt:

pip install -r requirements.txt

Tras esto tendremos que crearnos nuestra base de datos con postgres:

sudo su - postgres
psql -c "create user decide with password 'decide'"
psql -c "create database decide owner decide"

Entramos en la carpeta del proyecto (cd decide) y realizamos la primera migración para preparar la base de datos que utilizaremos:

python ./manage.py migrate

Por último, ya podremos ejecutar el módulos o módulos seleccionados en la configuración de la siguiente manera:

python ./manage.py runserver

Existe una configuración de docker compose que lanza 3 contenedores, uno para el servidor de base de datos, otro para el django y otro con un servidor web nginx para servir los ficheros estáticos y hacer de proxy al servidor django:

• decide_db
• decide_web
• decide_nginx

Además se crean dos volúmenes, uno para los ficheros estáticos y medias del proyecto y otro para la base de datos postgresql, de esta forma los contenedores se pueden destruir sin miedo a perder datos:

• decide_db
• decide_static

Se puede editar el fichero docker-settings.py para modificar el settings del proyecto django antes de crear las imágenes del contenedor.

Crear imágenes y lanzar contenedores:

$ cd docker
$ docker-compose up -d

Parar contenedores:

$ docker-compose down

Crear un usuario administrador:

$ docker exec -ti decide_web python ./manage.py createsuperuser

Lanzar la consola django:

$ docker exec -ti decide_web python ./manage.py shell

Lanzar tests:

$ docker exec -ti decide_web python ./manage.py test

Lanzar una consola SQL:

$ docker exec -ti decide_db ash -c "su - postgres -c 'psql postgres'"

Existe una configuración de vagrant que crea una máquina virtual con todo lo necesario instalado y listo para funcionar. La configuración está en vagrant/Vagrantfile y por defecto utiliza Virtualbox, por lo que para que esto funcione debes tener instalado en tu sistema vagrant y Virtualbox.

Crear la máquina virtual con vagrant:

$ cd vagrant
$ vagrant up

Una vez creada podremos acceder a la web, con el usuario admin/admin:

http://localhost:8080/admin

Acceder por ssh a la máquina:

$ vagrant ssh

Esto nos dará una consola con el usuario vagrant, que tiene permisos de sudo, por lo que podremos acceder al usuario administrador con:

$ sudo su

Parar la máquina virtual:

$ vagrant stop

Una vez parada la máquina podemos volver a lanzarla con vagrant up.

Eliminar la máquina virtual:

$ vagrant destroy

El provisionamiento de la aplicación con vagrant está hecho con Ansible, algo que nos permite utilizarlo de forma independiente para provisionar una instalación de Decide en uno o varios servidores remotos con un simple comando.

$ cd vagrant
$ ansible-playbook -i inventory playbook.yml

Para que esto funcione debes definir un fichero inventory con los servidores destino.

Los scripts de ansible están divididos en varios ficheros .yml donde se definen las diferentes tareas, por lo que es posible lanzar partes independientes:

• packages.yml, dependencias del sistema
• user.yml, creación de usuario decide
• python.yml, git clone del repositorio e instalación de dependencias python en virtualenv
• files.yml, ficheros de configuración, systemd, nginx y local_settings.py
• database.yml, creación de usuario y base de datos postgres
• django.yml, comandos django básicos y creación de usuario admin
• services.yml, reinicio de servicios, decide, nginx y postgres

Por ejemplo este comando sólo reinicia los servicios en el servidor:

$ ansible-playbook -i inventory -t services

El provisionamiento de ansible está diseñado para funcionar con ubuntu/bionic64, para funcionar con otras distribuciones es posible que haga falta modificar el fichero packages.yml.

El versionado de API está hecho utilizando Django Rest Framework, y la forma elegida para este versionado es mediante parámetros de búsqueda, podemos cambiarlo a parámetros en la URL o en el nombre del HOST, hay diferentes tipos de versionado disponibles en Django Rest Framework, podemos verlos aqui.

Nosotros hemos escogido el de por parámetros por ser el más sencillo, y hemos creado un ejemplo para que veamos su uso, podemos verlo en voting/views.py

Si nosotros queremos que la salida que nos da la llamada a la API /voting/, sea diferente en la versión 2, solo tenemos que comprobar en la versión nos está llegando, y hacer lo que queramos, por ejemplo:

    def get(self, request, *args, **kwargs):
        version = request.version  # Con request.version obtenemos la versión
        if version not in settings.ALLOWED_VERSIONS:  # Versiones permitidas
            version = settings.DEFAULT_VERSION  # Si no existe: versión por defecto
        # En el caso de usar la versión 2, usamos un serializador diferente
        if version == 'v2':
            self.serializer_class = SimpleVotingSerializer
        return super().get(request, *args, **kwargs)

Para llamar a las diferentes versiones, haremos lo siguiente:

• /voting/?version=v1
• /voting/?version=v2

Antes de empezar, comentaré para que sirven las pruebas de estrés. A veces necesitamos soportar que nuestra aplicación ofrezca una cantidad de peticiones por segundo, porque habrá mucha gente entrando a la misma vez, y ante este estrés, tenemos que comprobar como se comporta nuestra aplicación.

No es lo mismo que cuando la estresemos nos de un error 500 a que nos devuelva la petición de otro usuario. Con estos test conseguiremos comprobar cual es ese comportamiento, y quizás mejorar la velocidad de las peticiones para permitir más peticiones por segundo.

Para ejecutar los test de estrés utilizando locust, necesitaremos tener instalado locust:

$ pip install locust

Una vez instalado, necesitaremos tener un fichero locustfile.py donde tengamos la configuración de lo que vamos a ejecutar. En nuestro caso, tenemos hecho dos ejemplos:

1. Visualizer: entra en el visualizador de una votación para ver cuantas peticiones puede aguantar.

   Para ejecutar el test de Visualizer, tenemos que tener en cuenta que entra en la votación 1, por lo que necesitaremos tenerla creada para que funcione correctamente, una vez hecho esto, podemos comenzar a probar con el siguiente comando (dentro de la carpeta loadtest):

    $ locust Visualizer
   

   Esto abrirá un servidor que podremos ver en el navegador, el mismo comando nos dirá el puerto. Cuando se abra, nos preguntará cuantos usuarios queremos que hagan peticiones a la vez, y como queremos que vaya creciendo hasta llegar a ese número. Por ejemplo, si ponemos 100 y 5, estaremos creando 5 nuevos usuarios cada segundo hasta llegar a 100.

2. Voters: utilizaremos usuarios previamente creados, y haremos una secuencia de peticiones: login, getuser y store. Sería lo que realizaría un usuario cuando va a votar, por lo que con este ejemplo estaremos comprobando cuantas votaciones podemos hacer.

   Para ejecutar el test de Voter, necesitaremos realizar varios preparos. Necesitaremos la votación 1 abierta, y necesitaremos crear una serie de usuarios en el censo de esta votación, para que cuando hagamos el test, estos usuario puedan autenticarse y votar correctamente. Para facilitar esta tarea, hemos creado el script de python gen_census.py, en el cual creamos los usuarios que tenemos dentro del fichero voters.json y los añadimos al censo utilizando la librería requests. Para que este script funcione, necesitaremos tener instalado request:

    $ pip install requests
   

   Una vez instalado, ejecutamos el script:

    $ python gen_census.py
   

   Tras esto, ya podremos comenzar el test de estrés de votantes:

    $ locust Voters
   

Importante mirar bien el fichero locustfile.py, donde existen algunas configuraciones que podremos cambiar, dependiendo del HOST donde queramos hacer las pruebas y del id de la votación.

A tener en cuenta:

• En un servidor local, con un postgres que por defecto nos viene limitado a 100 usuarios concurrentes, cuando pongamos más de 100, lo normal es que empiecen a fallar muchas peticiones.
• Si hacemos las pruebas en local, donde tenemos activado el modo debug de Django, lo normal es que las peticiones tarden algo más y consigamos menos RPS (Peticiones por segundo).