Discussion :

[Invité]

Bonjour,

Je me pose des questions sur le fonctionnement des mails de confirmation, càd de ces mails qu'on reçoit en s'inscrivant sur un site et qui permettent de valider l'intention d'inscription du membre, l'existence de son adresse mail et donc d'activer la création du compte.

J'ai pris connaissance du tuto de M. Gut mais comme il date de 2008, je ne sais pas si la méthode est toujours celle que les développeurs privilégient aujourd'hui, et surtout, je suis inquiétée par la sécurité des scripts proposés comme il y est fait usage de superglobales ($_POST, $_GET)...

Bref, je viens vers vous avant tout pour un questionnement relatif à la philosophie de fonctionnement du script que j'ai à créer.


Que puis-je faire de mieux que :

- stocker dans une table de ma DB une clé aléatoire qui se génère à l'inscription du membre, avec en plus une colonne "confirmation" de type BOOL
- envoyer au membre un email contenant un lien avec en paramètres (get) l'id du membre et sa clé aléatoire ; lien qui dirige vers un script qui récupère ces données, les traite en comparant ce qui est indiqué dans l'url et dans la DB, et fasse passer la colonne confirmation de FALSE à TRUE si les champs matchent ; puis qui redirige vers la page de connexion du site.

Avec une telle méthode, j'exploite le get, dont on dit qu'il faut se méfier par faute de la faille XSS.
Est-ce qu'une telle méthode est insécure (même si on passe par une messagerie, elle même protégée par email & mdp) ? trop simpliste? trop complexe? est-ce que ça a du sens de stocker des données pareilles dans la DB pour le maigre usage qu'on en fait?

Quelle est selon vous la meilleure méthode pour parvenir à activer un compte?

Merci.

[sabotage]

Une faille XSS peut avoir lieu quand un site affiche des données externes sans contrôle : une personne malveillante peut alors envoyer un lien contenant du code piégé à l'utilisateur.
Ici on n'affiche pas ce qu'on a reçu donc il n'y a pas de problème.

En complément de ce que fais déjà le script, tu peux ajouter une date limite pour la validation.

est-ce que ça a du sens de stocker des données pareilles dans la DB pour le maigre usage qu'on en fait?

Je n'ai pas trop compris cette question. C'est toi qui voit si tu veux valider l'email de l'utilisateur ou pas.

[Invité]

Ok, merci pour ces précisions, Sabotage !
Je suis contente que la logique de fonctionnement du script paraisse tenir la route et ne semble non sécurisée de prime abord.
Merci pour l'idée d'une date de validation, c'est intelligent, je vais p-e mettre ça en place.

Pour la dernière question, je me demandais si le fait de stocker la clé aléatoire dans la DB avait du sens puisqu'elle ne servait que pour et lors de la création du compte. Mais je ne me vois pas stocker ça dans un cookie. Ce n'est pas cette petite colonne qui va altérer les perfs de l'appli a priori
Il n'empêche que vous pourriez avoir une solution plus pertinente... (P-e un chron qui viderait la table toutes les semaines, ce qui rejoint par ailleurs la limite pour la date de validation...)

[rawsrc]

Salut,

Il n'empêche que vous pourriez avoir une solution plus pertinente... (P-e un chron qui viderait la table toutes les semaines, ce qui rejoint par ailleurs la limite pour la date de validation...)

ou à chaque accès en écriture, tu nettoies la table des données périmées
Et après chaque validation de compte tu peux aussi supprimer les données (dans ce domaine, il vaut mieux faire attention avant de supprimer les logs d'ouverture, d'activation ou de suppression de compte...)

[Invité]

Ok, j'intègre !
Merci pour vos retours, c'est précieux.