les DEVS WEB, VENEZ ICI pour répondre à ma question
33 messages
Mise à jour: il y a 7 mois
VoidMan
il y a 7 mois
T'as donné la réponse dans ton message, je sais pas à quoi tu t'attends
axilog
il y a 7 mois
Quel est le problème à ajouter une colonne isActive dans ta table ?
zuzizoza
il y a 7 mois
T'as donné la réponse dans ton message, je sais pas à quoi tu t'attends
ça m'embête de stocker l'utilisateur alors qu'il n'a pas validé son mail, surtout que dans la modèle décrit, si l'utilisateur par malheur ne valide pas son mail, il a l'impression qu'il n'y a pas créé de compte
s'il revient en créer un, ça va poser problème puisque le mail sera enregistré en DB
zuzizoza
il y a 7 mois
Quel est le problème à ajouter une colonne isActive dans ta table ?
j'ai répondu
Oreille_sale
il y a 7 mois
Y'a énormément d'external authentification qui font ça pour toi et mieux que le développer from scratch
zuzizoza
il y a 7 mois
Y'a énormément d'external authentification qui font ça pour toi et mieux que le développer from scratch
je sais et c'est le cas de clerk mais, je ne sais plus vraiment pourquoi, j'ai fait le choix de pas l'utiliser, notamment parce que j'ai mon propre système de token
zuzizoza
il y a 7 mois
ah oui aussi clerk ne me fournit pas les composants UI pour une app expo donc j'en ai pas tant vu l'intérêt
AyaHAUT
il y a 7 mois
je sais et c'est le cas de clerk mais, je ne sais plus vraiment pourquoi, j'ai fait le choix de pas l'utiliser, notamment parce que j'ai mon propre système de token
Bah bravo, tu te fais chier le rien du tout quoi.
zuzizoza
il y a 7 mois
Bah bravo, tu te fais chier le rien du tout quoi.
nn je travaille avec adonis et le système de token est préconfiguré
j'ai pas cherché à l'intégrer avec clerk mais peut-être qu'on pouvait avoir personnaliser le token je sais pas
zuzizoza
il y a 7 mois
en plus quand on veut stocker des données spécifiques c'est chiant avec clerk il faut créer un utilisateur dans la base de données de l'app
zuzizoza
il y a 7 mois
up
zuzizoza
il y a 7 mois
up bordle
3Virgule141592
il y a 7 mois
ça m'embête de stocker l'utilisateur alors qu'il n'a pas validé son mail, surtout que dans la modèle décrit, si l'utilisateur par malheur ne valide pas son mail, il a l'impression qu'il n'y a pas créé de compte
s'il revient en créer un, ça va poser problème puisque le mail sera enregistré en DB
Tu fais une loop, toutes les heures tu supprimes les comptes non activés ou un truc comme ça
zuzizoza
il y a 7 mois
Tu fais une loop, toutes les heures tu supprimes les comptes non activés ou un truc comme ça
oui je vais faire ça même si ça me semble pas la plus élégante des solutions
3Virgule141592
il y a 7 mois
zuzizoza
il y a 7 mois
oui je vais faire ça même si ça me semble pas la plus élégante des solutions
Tu peux aussi faire une autre table avec les comptes temporaires
Juliecornes
il y a 7 mois
Je comprend pas comment on peut s'intéresser au Back Ahi
zuzizoza
il y a 7 mois
Tu peux aussi faire une autre table avec les comptes temporaires
khey chatgpt m'a proposé mais ça n'a aucun sens de faire ça, comme tu l'as dit autant nettoyer la table principale toutes les heures
zuzizoza
il y a 7 mois
Je comprend pas comment on peut s'intéresser au Back Ahi
et tu fais comment sans back en fait ?
Enzo-Dragnir
il y a 7 mois
Fais une table ou tu places les emails temporaires que tu supprimes toutes les 24h.
Tu veux quoi de mieux ?
Juliecornes
il y a 7 mois
et tu fais comment sans back en fait ?
Je n'ai pas dit que c'était inutile, et encore heureux que des devs en fassent, je design (moi même des outils que je transmet par la suite aux fronts/back.
Mais j'arrive pas à comprendre comment ça peut vous intéresser.
3Virgule141592
il y a 7 mois
Juliecornes
il y a 7 mois
Je comprend pas comment on peut s'intéresser au Back Ahi
ça demande un peu de logique et de responsabilités par rapport au front
ArchOumaLinux
il y a 7 mois
oui je vais faire ça même si ça me semble pas la plus élégante des solutions
Tâche CRON avec un script qui tej les utilisateurs non vérifiés
Complexifie pas trop tes structures de données pour ce genre de préoccupations
zuzizoza
il y a 7 mois
Je n'ai pas dit que c'était inutile, et encore heureux que des devs en fassent, je design (moi même des outils que je transmet par la suite aux fronts/back.
Mais j'arrive pas à comprendre comment ça peut vous intéresser.
au contraire c'est le design qui me saoule
faut être un minimum artistique et bonjour les galères avec le responsive
MaggieLindemann
il y a 7 mois
ça m'embête de stocker l'utilisateur alors qu'il n'a pas validé son mail, surtout que dans la modèle décrit, si l'utilisateur par malheur ne valide pas son mail, il a l'impression qu'il n'y a pas créé de compte
s'il revient en créer un, ça va poser problème puisque le mail sera enregistré en DB
Pourquoi?
D'abord tu check si l'email est dans ta DB, puis tu check isActivated, si c'est false tu envoies la page “please verify”, et si c'est true le reste du code peut le considérer comme inscrit
ArchOumaLinux
il y a 7 mois
Je n'ai pas dit que c'était inutile, et encore heureux que des devs en fassent, je design (moi même des outils que je transmet par la suite aux fronts/back.
Mais j'arrive pas à comprendre comment ça peut vous intéresser.
"je ne comprends pas que les gens n'aient pas les mêmes centres d'intérêts que moi"
Enzo-Dragnir
il y a 7 mois
ça demande un peu de logique et de responsabilités par rapport au front
Ça fait bien longtemps qu'on a arrêté de faire tout sur le back et déplacé une bonne partie de la logique back en front.
Ton commentaire se fait vieux tout de même.
3Virgule141592
il y a 7 mois
MaggieLindemann
il y a 7 mois
Pourquoi?
D'abord tu check si l'email est dans ta DB, puis tu check isActivated, si c'est false tu envoies la page “please verify”, et si c'est true le reste du code peut le considérer comme inscrit
Le problème c'est que dans toutes les conditions sur ses users il va devoir rajouter && isActivated non ? S'il oublie
Juliecornes
il y a 7 mois
au contraire c'est le design qui me saoule
faut être un minimum artistique et bonjour les galères avec le responsive
Après je ne suis pas UI designer (même si je suis parfois obligé).
Mon rôle c'est surtout de comprendre le besoin business et le besoin utilisateur pour réfléchir à la proposition de valeur / concept / fonctionnalités / flow.
Mais oui, je comprend que chacun a ses propres goûts.
Mais le back j'ai l'impression que c'est juste de la prise de tête et une galère par possible
[Gryfon]
il y a 7 mois
Là comme ça j'aurais dit une URL signée ou un token temporaire avec un salt.
Le hic c'est qu'il faudrait que l'utilisateur, après avoir entré le code, "finalise" son compte en créant son mot de passe. Comme ça, ça t'évite de stocker le mot de passe dans l'URL ou le token.
Du coup, ben, quand il soumet le formulaire de finalisation, là tu peux créer l'utilisateur dans ta DB.
Mais perso je vois pas ce qui gène à stocker en DB et faire un cron pour vider les utilisateurs inactifs tout les "X" temps. Tu peux aussi prévenir que le code n'est valable que X temps et que le compte devra être récréé si le code n'est pas soumis à temps, comme ça l'utilisateur est prévenu
Enzo-Dragnir
il y a 7 mois
Après je ne suis pas UI designer (même si je suis parfois obligé).
Mon rôle c'est surtout de comprendre le besoin business et le besoin utilisateur pour réfléchir à la proposition de valeur / concept / fonctionnalités / flow.
Mais oui, je comprend que chacun a ses propres goûts.
Mais le back j'ai l'impression que c'est juste de la prise de tête et une galère par possible
Boarf, c'est aussi une façon de comprendre les besoins utilisateurs.
Au final c'est juste des lego que t'empiles.
axilog
il y a 7 mois
Le problème c'est que dans toutes les conditions sur ses users il va devoir rajouter && isActivated non ? S'il oublie
Ça dépend comment tu gères les utilisateurs connectés. Si tu considères qu'un utilisateur non activé ne peut pas se connecter, ça change rien à ta logique. Sinon, tu peux toujours créer une classe/des classes qui gèrent les droits des utilisateurs auxquels cas t'as pas à te faire chier à rajouter des conditions partout
zuzizoza
il y a 7 mois
Ça dépend comment tu gères les utilisateurs connectés. Si tu considères qu'un utilisateur non activé ne peut pas se connecter, ça change rien à ta logique. Sinon, tu peux toujours créer une classe/des classes qui gèrent les droits des utilisateurs auxquels cas t'as pas à te faire chier à rajouter des conditions partout
oui voilà j'utilise de toute façon un middleware d'auth
zuzizoza
il y a 7 mois