Quasi finito! Abbiamo inviato una mail di attivazione a abc@gmail.com. Segui le istruzioni nella mail per attivare il tuo account.
Se non arriva, controlla la cartella spam.
come messaggio anche quando l’indirizzo email esiste. Ho apportato delle modifiche al codice, ho hardcodato il messaggio di attivazione nel metodo create in userController come “Utente attivato”. Anche in questo caso il messaggio appare come sopra. Qualcuno può aiutare?
Quindi, i nostri requisiti sono: dobbiamo registrare in blocco gli utenti dal nostro database su Discourse. Non possiamo permettere agli utenti di attivare il proprio account Discourse via email, poiché lo facciamo tramite Firebase sulla nostra web app.
Quindi, ho fatto alcune ricerche sul codice di Discourse e ho commentato la parte nella funzione activate di userController che invia l’email, attivando direttamente l’utente in quel punto, in modo che restituisse la seguente risposta:
Ma da ieri ho iniziato a ricevere questa risposta:
success: true,
active: false,
message: ‘Quasi fatto! Abbiamo inviato un’email di attivazione a abc@gmail.com. Segui le istruzioni contenute nell’email per attivare il tuo account. Se non arriva, controlla la cartella spam.’
Come posso verificare se la mia API di registrazione utente sta chiamando la funzione create, o se c’è qualche tipo di caching che mi sta causando questo problema?
A meno che tu non stia apportando le modifiche in un plugin, l’aggiornamento di Discourse sovrascriverà qualsiasi modifica apportata al codice di Discourse. Potrebbe essere questo ciò che è successo?
Di quale plugin stai parlando? L’unico cambiamento che ho apportato è stato in users_controller nel codice di Discourse? Puoi aiutarmi solo con il codice? Voglio fare il debug usando il codice. Dimmi solo dove si trovano le rotte per la registrazione dell’utente: /u o /u.json per essere precisi.
Inoltre, se registro qualcosa in userController usando print, riuscirò a vedere il log nel terminale? Al momento non riesco.
Ho individuato il problema. Non stavo inviando correttamente password_confirmation e challenge dal mio payload, per cui veniva segnalato come richiesta sospetta. Ho apportato le modifiche necessarie e ora funziona. Ma qual è la logica alla base di questi due parametri, dato che continuano a cambiare?