Vous êtes presque terminé ! Nous avons envoyé un e-mail d'activation à abc@gmail.com. Veuillez suivre les instructions contenues dans l'e-mail pour activer votre compte.
Si l'e-mail n'arrive pas, vérifiez votre dossier spam.
en tant que message, même lorsque l’adresse e-mail existe. J’ai apporté des modifications au code : j’ai codé en dur le message d’activation dans la méthode create de userController avec « Utilisateur activé ». Même ainsi, le message apparaît comme ci-dessus. Quelqu’un peut-il m’aider ?
Nos exigences sont donc les suivantes : nous devons enregistrer un grand nombre d’utilisateurs depuis notre base de données vers Discourse. Par conséquent, nous ne pouvons pas permettre aux utilisateurs d’activer leur compte Discourse par e-mail, car nous effectuons cette activation via Firebase dans notre application web.
J’ai donc fait quelques recherches dans le code de Discourse et j’ai commenté la partie de la fonction activate dans le userController qui envoie l’e-mail et activé l’utilisateur directement, de sorte que la réponse suivante était renvoyée :
success: true,
active: false,
message: ‘Vous êtes presque prêt ! Nous avons envoyé un e-mail d’activation à abc@gmail.com. Veuillez suivre les instructions contenues dans l’e-mail pour activer votre compte. Si celui-ci n’arrive pas, vérifiez votre dossier de spams’
Comment puis-je vérifier si mon API d’enregistrement d’utilisateur appelle bien la fonction de création, ou s’il existe un type de mise en cache qui me cause ce problème ?
Sauf si vous apportez ces modifications dans un plugin, la mise à jour de Discourse écrasera toutes les modifications que vous avez apportées au code de Discourse. Est-ce que cela pourrait être ce qui s’est produit ?
De quel plugin parlez-vous ? Les seules modifications que j’ai apportées concernent le fichier users_controller dans le code de Discourse. Pouvez-vous simplement m’aider avec le code ? Je souhaite déboguer en utilisant ce code. Veuillez m’indiquer où se trouvent les routes pour l’inscription des utilisateurs : /u ou /u.json pour être précis.
De plus, si j’ajoute un message de journalisation dans le UserController en utilisant print, pourrai-je voir ce log dans le terminal ? Pour l’instant, je n’y arrive pas.
J’ai trouvé le problème. Je n’envoyais pas le bon password_confirmation et challenge dans mon payload, ce qui entraînait le signalement de la requête comme suspecte. J’ai apporté les modifications nécessaires et cela fonctionne désormais. Mais quelle est la logique derrière ces deux paramètres, puisqu’ils continuent de changer ?