Closed nabiu256 closed 2 years ago
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í.
Perfecte, em sembla bona idea com ho proposes. Ara ho parlem després de la daily.
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.
validation_code
(PositiveIntegerField
), code_expires_at
(DateTimeField
) i validated
(DateTimeField
) per al model User
.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.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.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é.
(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:
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:
Desavantatges:
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:
Desavantatges:
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