Validació per codi en el registre d'un nou usuari

[nabiu256]

(Issue original amb la discussió del es possibles maneres d'implementar la validació d'un nou registre: #21)

Funcionament

Com hem decidit, el registre d'un usuari nou implica la validació del correu electrònic per poder ser vàlida. Això funcionaria a partir de:

1. En un primer pas, l'usuari afegeix les dades necessàries, entre elles, el correu electrònic.
2. Al passar a la següent pàgina, s'envia una sol·licitud perquè el servidor envii un correu electrònic amb el codi de confirmació al mail especificat, i es presenta un formulari a l'usuari per introduïr aquest codi.
3. Si l'usuari introdueix el codi correctament, es fa la sol·licitud al back per registrar un nou usuari.

Idees per a l'implementació

Bloqueig d'usuari fins a confirmació

Un usuari introdueix les dades necessàries per crear un nou usuari i a l'apretar Sign Up es fa una POST request al servidor. El servidor agafa les dades, les valida, i si tot està correcte, crea un usuari nou amb un camp (nou) que determina que aqeust usuari està pendent de confirmació.

Mentre aquest camp "pendent de confirmació" sigui True, qualsevol intent de log in amb aquest usuari portarà a una URL de confirmació del codi. Si un usuari ha estat creat i no ha confirmat el correu en un periòde X, el servidor borra l'usuari de la base de dades.

Avantatges:

• Permet fer una implementació més senzilla en tan que requests: com el back s'encarrega de la informació a cada pas, la view del formulari de registre i la view del formulari del codi de confirmació poden estar totalment separats.

Desavantatges:

• S'ha d'ampliar amb un camp més el model d'usuari, i és un camp que s'utilitza dins un cas molt molt específic i de curta durada, i per res més.
• S'ha d'implementar un sistema perquè el servidor netegi de manera regular els usuaris que s'hagin intentat crear i no s'hagin confirmat. És un cas poc probable però que podria ser i que definitivament podria ser explotat.

Una sola view, peticions a API des del front

L'usuari introdueix les dades per la creació d'un nou compte. El front fa una petició a un endpoint del back perquè li confirmi que les dades són vàlides (l'usuari no existeix ja, al contrasenya compleix les característiques necessàries, etc). Si el back confirma que és correcte, també enviarà el correu electrònic amb el codi de confirmació.

Si tot retorna correcte, el propi front mosta un segon formulari amb el camp per introduïr el codi de confirmació. Quan l'usuari l'introdueixi i faci submit, s'enviarà una request a un endpoint, enviant tan les dades de registre com el codi de confirmació. Aquí el back si confirma que tot és correcte, registrarà el nou usuari, i si no retorna l'error.

Avantatges:

• Sembla una experiència d'usuari millor, ja que no se'l redirigeix a cap altra URL enmig del procés.
• Es fan requests més lleugeres (només s'ha de retornar un petit JSON amb un simple missatge o dades)

Desavantatges:

• S'ha d'implementar una API, que no tenim per ara.
• El front esdevé prou més complicat (ha de fer requests a una API i modificar-se segons la resposta)
• El front del boilerplate de moment està purament amb tempates de Django i per tan tractar tema de l'estat i tal entenc que requeriria la incorporació de React.

Híbrida

Es fan requests tal qual al servidor, però en comptes de que sigui el back que guardi a la base de dades l'usuari en procès de registrar-se, és el front que el té en la seva informació d'estat i qui, finalment, si tot va bé retorna tan la info de l'usuari com el codi de confirmació al back perquè acabi el procés de registre.

Desconec si és possible i com es faria amb Django, ja que tot i que coneixo React, no sé del tot com interactua amb Django.

Recursos interessants

• Everything You Need To Know About Transactional Email
• Good practices for registration emails
• Email registration best practices
• 7 Types Of Registration Confirmation Emails And Subject Line Examples

[perepicornell]

Molt útil i guai l'anàlisi! Li he donat moltes voltes.. Proposo que fem cas a la metodologia i anem a passos: mirem de tenir de moment el sistema més senzill i ja farem iteracions, quan calgui, per avançar cap a coses més pijes amb ajax o el que sigui. Per tant jo em decantaria per la Bloqueig d'usuari fins a confirmació.

D'aquesta opció, de moment m'oblidaria del tema de netejar la base de dades, ja ho posarem al backlog per fer-ho més endavant.

Lo del camp per desar el codi de validació... realment serien 2 camps ja que necessitarem el codi i la data de caducitat. Per simplicitat, de moment els posaria al model User, i deixaria al backlog apuntada la tasca de fer un refactor per crear un model dedicat a les validacions o alguna cosa així.

[nabiu256]

Perfecte, em sembla bona idea com ho proposes. Ara ho parlem després de la daily.

[perepicornell]

• [x] Model User: afegir camps codi (numèric que es pugui teclejar) i camp data de caducitat + camp datetime de si el mail està validat o no (Null si no està validat).
• [x] Admin: mostrar aquests camps nous.
• [x] Data migration d'emails que ara és a base, moure-la a app users.
• [x] Afegir a la data migration el template d'email per la validació.
• [x] Model User o a alguna banda: crear un mètode per generar i desar el codi de validació i data de caducitat.
• [x] Crear mètode que faci l'enviament del mail de verificació.
• [x] A la view de signup, on form valid, generar i desar el codi de validació i fer l'enviament del mail.
• [x] A la view de signup, que també autentiqui l'user amb les credencials, i que el succes url sigui la pàgina de validació de mail.
• [x] Crear middleware que vagi després de login required que miri si tens el mail validat, en cas que no, et redirigeixi a la pàgina de verificació del mail.
• [x] Crear la view de validació a partir del codi
• [x] Netejar TODOs de codi hardcodejat i altres. Acabar de documentar i posar type hints.
• [x] Crear Redirect View per reenviar codi de confirmació al mail.

[nabiu256]

Em deixo aquest comentari per a mi per tenir apuntada la documentació de la implementació feta i coses a investigar/pensar durant el procés.

Implementació

1. Creats els camps validation_code (PositiveIntegerField), code_expires_at (DateTimeField) i validated (DateTimeField) per al model User.
2. Camps afegits a UserAdmin per mostar-se. He modificat també el UserCreationForm per tal que quan es crea un usuari des de l'admin, aquest es validi automàticament amb la data de creació, durant el save(). La idea és que excepcionalment podria ser necessari crear usuaris des de l'admin, i això necessitaria també saltar-se el procés de validació. Aquesta modificació ho soluciona.

Dubtes, problemes, etc

• Startup commands container: ara mateix com estan les migracions, si simplement es treu la migration inicial 0001_initial de l'app d'users, a l'haver-hi la segona migration (la data migration del superuser), la comanda makemigrations no detecta els canvis del model User i tot peta. He hagut de treure el contenidor i per fer el makemigrations haig de moure fora de la carpeta de migrations la data migration, fer el makemigration i llavors tornar-la a moure-la a dins abans de fer. No és un procés excessivament feixuc i és només un tema de develop, però no és gaire ideal.
• Mail context: per alguna raó la template no renderitza amb el context que li passo. No m'he mirat com funciona el post-office, però suposava que context era com sempre un diccionari amb parells nom_variable/valor que surt a la template. Tampoc és una cosa extremadament vital, així que m'ho miraré més endavant per no encallar-me aquí.
• Si poso el backend de mail de console, el contenidor de Docker no m'imprimeix com s'envia el correu (?)
• Created_by: no acabo d'entendre com funciona en alguns punts el created_by del BaseModel, ja que tot i ser un camp amb blank=False, els Forms genèrics no li donen cap valor i passen sense problema, mentre que si intento crear un usuari de manera programatica llavors em dona error si no li dono algun valor. Proposta: seria molt problema fer que fos blank=True? Això evitaria tot el tema i igualment quan un admin creei instancii un model des de la part d'admin seguim tenint la informació. Sí que és veritat que llavors en certs punts potser se'ns podria oblidar de suplir la informació, però bé.

Altres

• HackSoft Style guide: m'he mirat la guia per sobre i entenc com volen fer lo de la lògic de negoci en serveis. He vist més coses encara que em semblen interessants, i em semblaria bona idea en algun moment mirar-les conjuntament per veure quines ens agraden, quines no i implementar-les en la boilerplate.