Documentación de proyecto subsistema Autenticación - EGC-Decide/locaste GitHub Wiki
- Abreu Vázquez, Francisco Javier: 5
- Borge Sánchez, Santiago: 5
- Calzado Llamas, Ángel Manuel: 5
- Mármol Fernández, Ángel María: 5
- Rus Pegalajar, Luis: 5
- Repositorio de código
- Rama autenticación
- Sistema desplegado
-
Herramienta integración continua
- Gitflow
- Trabajo en Opera
- Resumen
- Introducción y contexto
- Descripción del sistema
- Planificación del proyecto
- Entorno de desarrollo
- Gestión de incidencias
- Gestión de la depuración
- Gestión del código fuente
- Gestión de la construcción e integración continua
- Gestión de liberaciones, despliegue y entregas
- Mapa de herramientas
- Ejercicio de propuesta de cambio
- Conclusiones y trabajo futuro
Nuestro proyecto se centra en mejorar el módulo de autenticación añadiéndole nuevas funcionalidades y ofreciendo estos servicios a los demás subsistemas.
El principal problema que tenía el sistema base respecto a este módulo era que no existía la posibilidad de que una persona pudiera registrarse en la aplicación, teniendo que hacerlo el administrador. Así que, tras dar solución a este problema, seguimos añadiendo otras funcionalidades que fueran útiles para el usuario. Se han implementado solo algunas de las mejoras pensadas, por lo que hay espacio de mejora en el caso de continuar con el proyecto.
Las votaciones surgen de la necesidad de tomar decisiones entre dos o más personas. Existen diferentes formas de votar como por ejemplo a mano alzada o introduciendo el voto en una urna. Además, el voto puede ser de distintos tipos (público, privado, con pesos...).
El voto electrónico es el uso de ordenadores para realizar una votación, bien sea a través de internet o de forma presencial. Ésto tiene la ventaja de tener un bajo coste y además ser más accesible para personas con movilidad reducida y votantes que se encuentran lejos entre ellos. En contraposición, el voto electrónico es más complejo de auditar, puede ser atacado más fácilmente por ciberdelincuentes y hace más fácil la compra de votos y la extorsión a la hora de votar.
Existen varios tipos de voto electrónico:
- Voto público
- Voto secreto sin cifrado
- Voto secreto con cifrado
El voto público sería el más fácil de implementar, mientras que para el voto secreto sin cifrado y con cifrado debemos tener plena confianza en los administradores y en autoridades respectivamente.
Decide es un sistema de voto electrónico educativo que implementa un sistema básico de votación electrónica con voto secreto y criptográficamente seguro punto a punto. Además, es un sistema modular y extensible basado en subsistemas (módulos).
Este sistema de software libre (código en https://github.com/wadobo/decide) aporta una implementación de referencia y permite su extensión en cualquier tecnología cumpliendo una API web básica.
Decide consta de 8 módulos independientes, los cuales no dependen de un lenguaje de programación y están conectados mediante APIs. Gracias a esto podemos distribuir la carga en diferentes máquinas y se simplifica a la hora de abordar una tarea concreta.
Como podemos observar en la ilustración, decide se divide en 8 módulos conectados entre ellos más un módulo base que se encarga de las funcionalidades comunes.
A continuación, explicaremos en que consiste cada uno de estos módulos.
-
Auth (autenticación)
Permite la autenticación de los votantes.
-
Census (censo)
Este módulo se encarga de guardar quién puede votar y quién ha votado.
-
Voting (votación)
En este módulo se definen las votaciones (preguntas, opciones, tipo de voto, etc).
-
Booth (cabina)
Booth se encarga de la cabina de votación en la que entrará el votante para emitir su voto.
-
Mixnet
Éste módulo se encarga de la parte criptográfica. La mixnet sería una red de ordenadores (1 a n), los cuales generan una clave compartida para cifrar votos, por lo que solo se podrán descifrar los votos, una vez todas se pongan de acuerdo. En el recuento, el votante se desliga del voto, ya que cada autoridad realiza un barajado y se lo pasa a la siguiente, anonimizando el voto.
-
Postproc (postproducción)
Realiza el postprocesado del voto, utilizando los resultados del recuento para generar un resultado coherente al tipo de votación.
-
Visualizer (visualización)
Visualizador de datos. Parte de frontend en la que mostramos de la forma más visual posible los resultados obtenidos.
-
Store
Se encarga de almacenar los votos cifrados.
Los cambios desarrollados por nuestro subsistema son los siguientes:
- Cambio de la API de autenticación
- Funcionalidad de registro de usuarios
- Añadir género y edad al registro
- Permitir que el usuario pueda ver su perfil y editar su género y edad
- Iniciar sesión con redes sociales (Facebook, Twitter y Google)
- Votar con redes sociales
- Añadir nuevos templates para las páginas de autenticación y que partan de un template base.
- Añadir CSS a las páginas del módulo de autenticación
- Añadido menú de navegación para la aplicación
- Añadido Catpcha al registro
Con respecto a la planificación del proyecto, se ha llevado a cabo teniendo en cuenta siempre que cada uno de los miembros del equipo tenía que encargarse de realizar un incremento.
Los incrementos desarrollados por cada miembro son:
-
Cambio de la API de autenticación
-
Funcionalidad de registro de usuarios
-
Añadir género y edad al registro
-
Permitir que el usuario pueda ver su perfil y editar su género y edad
-
Iniciar sesión con Facebook
-
Iniciar sesión con Twitter
-
Iniciar sesión con Google
-
Votar con redes sociales
-
Añadir nuevos templates para las páginas de autenticación y que partan de un template base
-
Añadir CSS a las páginas del módulo de autenticación
-
Añadido menú de navegación para la aplicación
-
Añadido Catpcha al registro
Los deadlines seguidos internamente en el equipo son los milestones establecidos por la asignatura:
-
Milestone 1 (Martes 27 de noviembre)
-
Milestone 2 (Martes 18 de diciembre)
-
Milestone 3 (Martes 14 de enero)
Por esto para el primer milestone debíamos tener el sistema funcionando con el primer incremento que era el registro, aunque posteriormente fuera modificado. Para el segundo milestone avanzamos significativamente con las demás iteraciones funcionales y mejoramos el primer milestone. Por último para el tercer milestone ya teníamos todos los incrementos desarrollados y el sistema funcionando correctamente.
El reparto de tareas en general ha sido equitativo, aunque haya tareas en las se ha tenido que invertir más tiempo que en otras. El progreso de cada uno de los miembros del equipo se puede ver en el diario del grupo.
Durante el desarrollo del proyecto cada miembro ha usado uno de los dos siguientes IDE:
-
Visual Studio Code, el IDE gratuito de Microsoft. La versión usada por los integrantes ha sido la 1.30.
Para instalarlo, basta con seguir los pasos indicados en el ejecutable que se puede descargar en la web. Además de usarlo para programar en python, también se ha hecho uso de la integración del IDE con git para agilizar los procesos de gestión de código.
-
Atom(versión 1.34.0). Por sí solo, Atom no es un entorno de desarrollo. Para convertirlo en uno, se han añadido los paquetes indicados en Atom IDE.
Una vez que se descargue y se instale Atom, tendremos que añadir los paquetes indicados en el enlace anterior para convertirlo en un entorno de desarrollo. Para ello, seleccionamos la opción “Install Package” en la pestaña de bienvenida. En la nueva ventana, deberemos introducir el nombre de los paquetes a instalar:
- Paquete atom-ide-gui (versión 0.13)
- Paquete ide-python (versión 1.2.0)
Al tratarse de una herramienta desarrollada por GitHub, Atom no necesita ningún paquete externo para integrarse con git.
Para todo el proceso referidos a incidencias, ya sea desde el momento en el que se reporta hasta que se finaliza, la herramienta utilizada para ello ha sido GitHub. Ahora vamos a explicar todo el ciclo de vida que se llevó a cabo.
Decir previamente que toda la información que se compartió de cara a llevar a cabo una incidencia debió ser proporcionada en Inglés. Además, el proceso llevado a cabo ha sido el mismo para la gestión de incidencias internas y externas.
Cuando sucede una incidencia, la persona que da el reporte tenía que dirigirse al siguiente enlace: Tablero del proyecto. A continuación, mostramos a donde nos lleva:
Aquí podemos observar primero, todo el conjunto de notas referidas a issues que ha llevado a cabo el proyecto. Como segundo, podemos ver los diferentes estados por los que pasó una Issue, el cual se representan en GitHub como tableros. Enumerados serían:
- To do: La incidencia ha sido creada por la persona que ha encontrado o un problema en el proyecto o una necesidad.
- WIP (Work In Progress): Una vez el coordinador del subsistema correspondiente la ha aceptado, la persona encargada a ello empieza a trabajar en el plazo previamente descrito en el estado 1.
- In Review: El trabajador de la issue informa al coordinador y este hace una prueba de cómo de acabado está haciendo pruebas de ello.
- Done: Una vez el coordinador acepta el trabajo realizado, se encarga de informar a los demás coordinadores de que ya está el trabajo hecho y lo une con el resto del proyecto.
Así pueden resumirse los pasos que se llevaron en la realización de una issue. Durante la explicación referenciamos cada uno de ellos.
Volviendo al paso 1. La persona en esta vista, tuvo que dirigirse al tablero “To do” para añadir una nueva nota (pulsando +) en la que ponía como título de esta un breve resumen de la necesidad o problema y en la descripción toda la información posible que pudiera ayudar a el análisis del problema y cómo actuar ante él.
Una vez la crea pulsa “...” para convertirla en issue y poder dotarla de etiquetas que muestren la categoría, prioridades y un rol que se asigne a ella.
Una vez pasamos de nota a issue vemos lo siguiente.
Aquí debió aportarse información adicional si fue necesaria y en el apartado “Labels” se añadió cada una de las etiquetas para describir lo que hemos hablado anteriormente. Se pueden enumerar de la siguiente manera:
Se emplean las que ya trae GitHub, estas son:
- bug: La incidencia describe un fallo de programación en el software.
- duplicate: Ya existe otra incidencia que describe los mismo que ésta.
- enhancement: Una solicitud de mejora en el software.
- good first issue: Esta incidencia es idónea para un desarrollador del equipo junior, o con menor experiencia en el software.
- help wanted: Esta incidencia describe una petición de ayuda.
- invalid: Esta incidencia es incorrecta, refleja una petición que no tiene sentido.
- question: Esta incidencia describe una pregunta a responder para el equipo de desarrollo.
- wontfix: Esta incidencia no tiene solución posible. Se emplea cuando se describe como incidencia un comportamiento que parece ser defectuoso, pero que en realidad es una funcionalidad. También se puede emplear para una incidencia que describe un problema, para la que no existe solución posible. Hay que tener una buena razón para etiquetar una incidencia de esta manera.
Además, se han añadido etiquetas para marcar qué subsistema está encargado de la incidencia, por lo tanto existen las siguientes:
- auth: subsistema de autenticación.
- booth: subsistema de cabina de votación.
- census: subsistema de censo.
- display: subsistema de visualización.
- postproc: subsistema de post-procesado de votos.
- voting: subsistema de votación.
Los tipos de prioridades que existen son los siguientes:
- critical: máxima prioridad lo que requiere que se solucione de inmediato.
- high: requiere que se solucione en el periodo de tiempo de uno a tres días. neutral: requiere que se solucione en un periodo de tiempo de tres a siete días.
- low: no se requiere un tiempo de solución específico y es posible ni siquiera solucionarlo.
Luego en el apartado “Assignees” se definía el dueño y el encargado de la incidencia.
Una persona que quiso llevar a cabo la solución de la incidencia tenía que informar a su coordinador para poder realizarlo y este ponerse en contacto con los demás jefes para que pudieran estar al tanto de la situación de esta. Una vez se aceptó la nota (guardada en la web de la ilustración x) debía moverse al siguiente estado: WIP definido anteriormente en el paso 1.
Durante el desarrollo de una incidencia se llevaron a cabo procesos de “gestión del código fuente”, más información en el apartado con el título.
Una vez el encargado de la incidencia consideraba solucionado el problema, informaba nuevamente al coordinador de su subsistema y la nota pasaba a la tabla de “In review”. Entonces, coordinador comenzaba con las labores de revisión en las cuales, probaba el trabajo realizado y hacía una serie de pruebas para validar que se cumplía con lo requerido e incluso se comunicaba con el dueño de la incidencia para validar el criterio de aceptación que se exigía.
Cuando se tiene plena garantía de que el trabajo está bien hecho, se llevaban a cabo procesos de “Integración Continua” (Ver el apartado con este título) y el coordinador del subsistema al que se refería la incidencia la cerraba y la nota pasaba al estado “Done” (Ver el tablero en la ilustración x).
Para la gestión de la depuración de código, hemos seguido el siguiente procedimiento:
Cuando un usuario encuentra un bug en el sistema que quiera notificar, crea la issue con los siguientes datos:
Fecha de inicio: dd/MM/YYYY
Descripción: Descripción detallada del problema. Salvo que la forma de obtener el bug sea un caso excepcional, el esquema a seguir, como podemos ver en la wiki del grupo, es el siguiente:
1.x
2.y
3.z
Salida esperada. Salida real:
Versiones y sistema operativo que se usa:
Información adicional:
Además, la issue tendrá que tener la etiqueta asignada de bug, la etiqueta del módulo o módulos implicados y la etiqueta de prioridad: critical, high, neutral o low.
A partir de ese momento, la gestión de la issue se realiza según lo expuesto en el apartado anterior. Podemos ver un ejemplo de gestión de depuración en la issue #77.
En cuanto a la gestión del código fuente la herramienta que hemos usado es Git con la plataforma Github para alojar el repositorio.
Con respecto a cómo hacer commits, decidimos ponernos de acuerdo con el resto de subsistemas, con lo que establecimos un formato para realizar dichos commits:
Los commits deberán seguir el siguiente formato:
[Tipo]: <Breve descripción>.
<Más información, si es necesario>
El título del commit no debe superar los 80 caracteres, si fuera necesario extenderse más se usaría el apartado destinado a añadir más información.
-
feat: (nueva característica)
-
fix: (corrección de bug)
-
docs: (Cambios a documentación)
-
style: (formateo de código o cambios en el estilo del mismo)
-
refactor: (Refactorización del código)
-
test: (Relacionado con tests)
-
chore: (No hay cambios en el código)
Podrían usarse otros tipos pero de forma muy intuitiva (e.g. Global, un commit que afectaría a todo el proyecto)
La frecuencia de los commits no seguía una regla concreta, si no que se dejaba a juicio de cada miembro, normalmente todos hacíamos commit cuando veiamos que teníamos algo funcionando, aunque luego tuviera que ser modificado en caso de errores. Aquí puede verse un ejemplo de commit el cual sigue el formato antes mencionado.
La forma de gestionar el repositorio de código era similar a un modelo centralizado en el que todos los miembros trabajaban contra un mismo repositorio central compartido.
Para llevar a cabo de forma correcta la integración lo hacíamos mediante ramas. Podemos verlo de forma más clara en la Ilustración 6 con un ejemplo de nuestro subsistema. La rama principal era el “master” donde todo lo que había funcionaba y estaba correctamente integrado. Luego había otra rama de desarrollo llamada “dev” en la que se subían las funcionalidades de manera aislada y se realizaba la integración, con el objetivo de detectar fallos antes de llevarlo a master (Para llevar algo de la rama dev a la rama master se hacía mediante Pull request, el cual era aceptado por un coordinador de subsistema, que normalmente era aquel que lo crea). A continuación teníamos una rama por cada subsistema, donde cada equipo trabaja de forma aislada y llevaba a cabo sus funcionalidades. Por último de forma opcional se podía crear una rama por funcionalidad para desarrollar ahí la funcionalidad concreta antes de llevarla a la del subsistema.
Para la construcción de dependencias de herramientas, cada subsistema que ha ido necesitando instalar nuevos paquetes o librerías lo ha escrito en el archivo requirements.txt para que los demás pudiéramos tener instalados dichos componentes también escribiendo:
pip -r requirements.txt
o para los que usan python3 junto a otras versiones
pip3 -r requirements.txt
Para incluir la herramienta para la construcción y pruebas de nuestro código creamos el fichero “.travis.yml” cuyo contenido se muestra a continuación.
Una vez teníamos el archivo en la raíz del repositorio, ya podíamos iniciar la build de Travis, aparecía de la siguiente manera:
El modelo de integración empleado ha sido “Sandwich” como se puede ver en la Ilustración x. Esto ha sido así debido a los diversos módulos que componían decide y a la necesidad de realizar cambios por todos los equipos. De esta forma se fueron integrando cambios según los distintos subsistemas querían, eso sí, siempre se informaba previamente a los demás coordinadores
Tras realizar una subida a alguna de las ramas principales de cada subsistema (aunque podía usarse en otra rama si se consideraba necesario), se usaba la herramienta Travis CI para realizar las pruebas del proyecto, en caso de que los test no dieran un resultado positivo, no se debía realizar ningún merge con la rama master hasta que el error estuviera solucionado. Tras la ejecución de los test, independientemente del resultado se notifica mediante correo electrónico a cada miembro el resultado.
A continuación se explicará cómo se han llevado a cabo las liberaciones, el proceso de despliegue y la entrega del proyecto.
En cuanto a las liberaciones, siempre irán relacionadas a una tag. Las tags hacen referencia a las distintas versiones
del proyecto y están enlazadas con commits. Para más información acerca de cómo administrar las liberaciones en Github
ver.
Se puede ver un ejemplo de liberación aquí.
La licencia elegida para el proyecto Decide-Locaste es una licencia de tipo copyleft, en concreto la AGPL 3.0. Esta licencia entre otras cosas especifica que el trabajo desarrollado a partir de código que esté bajo ella debe seguir teniendo la misma licencia. Por lo tanto, no podemos cambiarla ya que el proyecto parte de un fork de Decide que cuenta con una licencia de este tipo.
Sobre la política de nombrado e identificación que hemos seguido para las versiones de los entregables, el patrón utilizado es del tipo X.Y.Z. Donde:
- X: representa un cambio sustancial en funcionalidad.
- Y: representa un cambio menor en funcionalidad.
- Z: no representa un cambio en funcionalidad, pero si la solución de bugs o cambios menores en el proyecto.
El proceso seguido para el despliegue automático de la aplicación se iniciará una vez haya pasado correctamente las pruebas de integración continua. Para que este proceso forme parte de las fases de integración continua, hay que seguir una serie de pasos:
- Crear una nueva app en Heroku, configurar el Procfile y realizar los cambios necesarios al archivo settings.py. Más información.
- Añadir la información necesaria al archivo .travis.yml para la creación de un nuevo trabajo asociado a la
plataforma de despliegue, en este caso Heroku. Este nuevo trabajo se deberá ejecutar una vez los tests de la
aplicación hayan pasado correctamente. En el trabajo se deberá indicar entre otras cosas la api_key de Heroku, la
cual podemos obtener estando logeados en la cuenta de Heroku con la que hemos creado la app en el primer paso,
estando en la carpeta del repositorio de Github y utilizando el comando
travis encrypt $(heroku auth:token)
También habría que configurar varias opciones en la web de Heroku, un tutorial útil para entender estos pasos puede ser este. Una vez configurado todo lo necesario, al realizar un push a la rama master veremos como pasa automáticamente por las diferentes fases hasta desplegarse.
En el caso de querer crear un super usuario de Django, estando logeados en la cuenta propietaria de la app se utilizaría
el comando heroku run -a appname 'cd decide && python manage.py createsuperuser'
Para la entrega del proyecto, cada equipo de Decide-Locaste rellenará un formulario de Microsoft Office con la información correspondiente sobre:
- Nombre del proyecto
- Usuarios de git de los miembros del equipo utilizados para hacer los commits
- Incrementos realizados por cada miembro.
- URL del trabajo en Opera
- Tutor
- Subsistemas con los que se ha integrado
- URL del repositorio del código del proyecto
- URL del diario del grupo
- URL de la documentación del proyecto (este documento)
Para finalizar esta sección, comentar que aunque en un primer momento se habló de realizar más liberaciones, al final se decidió hacer solo una aunque estas no suponen un problema a la hora de desarrollar el proyecto.
Las aplicaciones usadas para la gestión de la configuración han sido Travis CI, git, GitHub y Heroku.
Mediante el repositorio git proporcionado por GitHub, el equipo ha gestionado el código de la aplicación y sus incrementos. Mediante la relación entre git y GitHub, se han podido realizar mejoras, crear y cerrar issues, asignar tareas o identificar y arreglar bugs.
Con cada push de git al repositorio remoto, se ha usado Travis CI para crear la build de la versión y ejecutar automáticamente los tests. En GitHub se ha podido acceder al resultado de dichos tests, así como ver los resultados de cada commit que se hizo.
Finalmente, el código de la versión final de la aplicación se ha desplegado en la nube mediante Heroku. Se puede acceder a la aplicación mediante este enlace.
A continuación se explicará paso por paso como se llevó a cabo un incremento, en concreto el de añadir la opción para poder registrarte en la aplicación. En el sistema base de Decide solo el administrador puede crear nuevos usuarios que pudieran votar. Por ello, se pedía que una persona pudiera registrarse por sí sola sin la necesidad del administrador.
En nuestro caso como también queríamos incluir en un futuro el inicio de sesión con redes sociales, decidimos cambiar la API de autenticación ya que la que viene de base no lo permite.
Creamos la issue, le asociamos las etiquetas correspondientes y la incluímos en el proyecto. En los commits relacionados con esta issue, la referenciaremos (e.g. #2). La ponemos en WIP ya que vamos a empezar a trabajar sobre ella.
Con la rama authentication creada en el repositorio local y remoto, lo primero que debemos de hacer es git checkout authentication, para que los cambios se realicen sobre esa rama.
Después, usando la consola, instalamos los paquetes django-rest-auth y django-allauth mediante los comandos
pip install django-rest-auth y pip install django-allauth.
También deberemos de incluir estos dos paquetes en el requirements.txt para que a las demás personas también se les instalen al introducir el comando pip install -r requirements.txt.
Añadimos rest-auth, django.contrib.sites, allauth, allauth.account y rest_auth.registration a la lista de INSTALLED_APPS y SITE_ID = 1 en el archivo settings.py de Django.
INSTALLED_APPS = [
......,
'rest_auth',
'rest_auth.registration',
'django.contrib.sites',
'allauth',
'allauth.account',
......
]
SITE_ID = 1En el archivo urls.py de authentication metemos dos nuevas URLs path('signup/',include('rest_auth.registration.urls')) que apunta a la API a la que se le enviarán los datos en JSON y path('sign-up/', SignupView.as_view(), name="signUp") a la que asociaremos un
html en el que se creará:
- Un formulario para que el usuario introduzca los datos necesarios para registrarse
- Métodos en JavaScript para mandar y recibir información sobre el usuario.
Haremos python manage.py migrate para crear lo necesario en la base de datos.
Ahora para subir estos cambios a la rama authentication del repositorio remoto haríamos:
git add .
git commit -m “-Este mensaje dependerá del formato de los commits acordado-”
git push
Con esto, y si no hay que resolver conflictos, tendríamos la función de registro en el repositorio remoto para que los demás utilicen nuestro código. Ahora nos pasariamos a la rama dev mediante el comando git checkout dev , actualizamos la rama en local con git pull y hacemos git merge authentication para integrar los cambios realizados anteriormente con la rama dev. Haríamos git push para subir los cambios en este caso a la rama dev. Por último, el coordinador de alguno de los subsistemas deberá hacer y aceptar un Pull Request de dev a master para integrar los cambios realizados en dev con la rama master.
En el caso de usar una herramienta de integración continua, como TravisCI, al hacer un push a una rama o al crear un Pull Request se ejecutarían los tests de la aplicación y si el resultado no es correcto, deberíamos solucionarlo. Si además de esto contamos con despliegue automático en una plataforma como Heroku, no solo se ejecutarían los tests sino que si los pasa y el push se realiza a la rama master, habría una fase de despliegue y podríamos finalmente ver nuestra aplicación desplegada en remoto.
Para finalizar, una vez que el código esté en master, la issue se dará por cerrada automáticamente si se ha hecho lo necesario para ello en el commit o la cerraríamos manualmente para evitar confusiones.
En general y gracias también al trabajo realizado por los demás subsistemas de Locaste, hemos mejorado bastante el sistema base de Decide. Comentar también que el no tener equipos dedicados al desarrollo de la mixnet o al subsistema de store ha hecho que los demás equipos tengamos que haberle dedicado algo de tiempo también a estos módulos.
Como mejoras a realizar en el futuro relacionadas con el subsistema de autenticación se propone:
-
Incorporar la opción de resetear la contraseña, ya que ahora mismo si se comete un error durante el registro en ella, no se puede cambiar.
-
Hacer obligatorio el campo “email” de los usuarios en el registro para hacer que lo verifiquen mediante un enlace a esa dirección de correo.
-
Unificar las cuentas (local y social) en una, de forma que puedas iniciar sesión con un usuario local con un determinado email y si se quiere, también se podría iniciar sesión mediante redes sociales a la misma cuenta si tiene el mismo email asociado.