Modifica dell'email di un utente

Sono un po’ confuso dal processo quando un amministratore modifica l’indirizzo email di un utente.

Alcune cose non mi sono chiare e c’è anche un bug (ecco perché pubblico qui in bug e non in #supporto).

  • Secondo questa pull request, il comportamento dovrebbe essere il seguente.

Quando un amministratore modifica l’email di un utente dalla pagina delle preferenze di quell’utente:

  • L’utente non riceverà un’email di conferma per il cambiamento dell’indirizzo. Riceverà invece un’email per la reimpostazione della password, così da poter impostare la password per il proprio account al nuovo indirizzo email.
  • L’utente riceverà comunque un’email al vecchio indirizzo per informarlo che è stato modificato.

#1 Non capisco perché venga inviata un’email di reimpostazione della password (“così da poter impostare la password per il proprio account”). Non hanno bisogno di cambiare la password? Inoltre, l’esperienza utente è confusa: l’utente non si aspetta un’email di reimpostazione della password, non c’è alcun testo esplicativo e il messaggio dice semplicemente “Qualcuno ha richiesto la reimpostazione della password su [nome del forum]”.

#2 Quell’email di reimpostazione della password viene inviata al vecchio indirizzo invece che al nuovo indirizzo email.

Anche se l’email dell’utente viene aggiornata in update_user_email alla riga 46, l’oggetto @user non viene ricaricato e contiene ancora il vecchio indirizzo email.

#3 Se l’amministratore è l’utente che compie l’azione e l’utente su cui si agisce non è personale, non viene inviata alcuna email di conferma come specificato sopra. Tuttavia, dopo aver modificato l’indirizzo email, l’amministratore riceve il seguente messaggio di successo: “Abbiamo inviato un’email a quell’indirizzo. Segui le istruzioni di conferma”.

#4 Perché l’utente non deve confermare il nuovo indirizzo email? La pull request fa riferimento a questo argomento, ma sembra che manchino molti post. Tuttavia, l’argomento menziona comunque: “Per un utente normale, l’unico indirizzo email che deve essere verificato è il NUOVO indirizzo email”. EDIT: aspetta, vedi #6 / #7.

#5 Questo processo, in cui un amministratore modifica l’email dell’utente, viene tipicamente utilizzato quando il vecchio indirizzo email non è più accessibile (immagino?). Perché viene comunque inviata una notifica al vecchio indirizzo?

#6 Quando questo utente tenta di accedere, appare un popup:

Non puoi ancora accedere. Abbiamo precedentemente inviato un’email di attivazione al tuo vecchio indirizzo email. Segui le istruzioni contenute in quell’email per attivare il tuo account.

  • Non è stata inviata alcuna email del genere
  • Viene menzionato il vecchio indirizzo email

Premendo il pulsante “Invia di nuovo” si legge:

Abbiamo inviato un’altra email di attivazione al tuo nuovo indirizzo email. Potrebbero volerci alcuni minuti prima che arrivi; assicurati di controllare anche la cartella spam.

#7 Quell’email di attivazione arriva effettivamente al nuovo indirizzo email ed è intitolata “conferma il tuo nuovo account” (e non “conferma il tuo nuovo indirizzo email”).

Non dovrebbe essere semplicemente così:

Viene inviata un’unica email al nuovo indirizzo email, con il messaggio: “Il tuo indirizzo email è stato modificato da [nome dell’amministratore]. Clicca sul seguente link per confermare [link].”

Modifica: #8 L’indirizzo email può essere modificato da un amministratore dal profilo pubblico dell’utente (/u/username), ma non dalla pagina amministrativa dedicata a quell’utente (/admin/users/id/username). Questo è controintuitivo.

10 Mi Piace

Possiamo riprodurlo @tshenry? C’è stata una regressione qui?

2 Mi Piace

Inizierò descrivendo il flusso attuale così come lo osservo (nella maggior parte, se non in tutti i casi, questo è in linea con quanto descritto da @RGJ):

  1. L’amministratore accede alle preferenze di un utente non staff e modifica il suo indirizzo email:

    Una volta inviato, l’amministratore visualizza il seguente messaggio:

    Abbiamo inviato un’email a quell’indirizzo. Segui le istruzioni di conferma.

  2. Il messaggio sopra non sembra accurato, poiché vengono inviate DUE email all’indirizzo email vecchio:

    [Demo] Il tuo indirizzo email è stato modificato

    Questo è un messaggio automatico per informarti che il tuo indirizzo email per
    Demo è stato modificato. Se ciò è stato fatto per errore, contatta
    un amministratore del sito.

    Il tuo indirizzo email è stato modificato in:

    new@email.com

    [Demo] Reimpostazione della password

    Qualcuno ha richiesto la reimpostazione della tua password su Demo.

    Se non sei stato tu, puoi ignorare tranquillamente questa email.

    Clicca sul seguente link per scegliere una nuova password:
    https://example.discourse.site/u/password-reset/74d53d7d2cf20dsbc360614844c653s2

  3. Ho testato tre scenari separati da questo punto. Ogni punto elenco rappresenta uno scenario distinto:

    • L’utente ha accesso all’email vecchia e segue il link per reimpostare la password. Dopo aver aggiornato la password, viene effettuato l’accesso. Da lì, può accedere con il proprio nome utente o con l’indirizzo email VECCHIO. La nuova email non sembra essere attiva in questo momento.

    • L’utente tenta di accedere con il proprio nome utente o con l’indirizzo email nuovo e riceve questo:

      Opzione 1: Premendo “Invia di nuovo” viene visualizzato il seguente messaggio (nota che questa volta menziona l’indirizzo email nuovo):

      Viene effettivamente inviata un’email all’indirizzo email nuovo:

      [Demo] Conferma il tuo nuovo account

      Benvenuto su Demo!

      Clicca sul seguente link per confermare e attivare il tuo nuovo account:
      https://example.discourse.site/u/activate-account/74d53d7d2cf20dsbc360614844c653s2

      Se il link sopra non è cliccabile, prova a copiarlo e incollarlo nella barra degli indirizzi del tuo browser web.

      Seguendo il link si passa attraverso alcune pagine per l’attivazione di un nuovo account. Alla fine l’utente accede correttamente. Da questo punto l’utente può accedere con il proprio nome utente o con l’indirizzo email VECCHIO. La nuova email non sembra essere attiva in questo momento.

      Opzione 2: Premendo il pulsante “Modifica indirizzo email” viene visualizzato quanto segue. Il pulsante “Aggiorna indirizzo email” è disabilitato quando l’indirizzo email nuovo è nel campo di testo, suggerendo che la nuova email sia già attiva (ma ciò non sembra essere vero).

    • L’utente avvia una reimpostazione della password. L’email viene inviata all’indirizzo email nuovo e l’utente può accedere tramite il link. Come negli altri scenari, l’utente può accedere con il proprio nome utente o con l’indirizzo email VECCHIO. La nuova email non sembra essere attiva in questo momento.

Quindi stiamo sicuramente riproducendo il problema qui. È difficile descriverlo chiaramente, ma spero che tra l’OP e questa panoramica, tutto risulti comprensibile. Certamente sembrano esserci alcune cose da correggere.

@martin So che hai lavorato in passato su questa parte del core. Potresti dare il tuo parere quando hai un momento?

9 Mi Piace

Perché questo dovrebbe essere peggiorato? :thinking:

modifica: Posso anche confermare che è peggiorato. Quando si modifica l’email di un utente regolare, la conferma e così via vengono inviate alla VECCHIA email. Non è così che funzionava in passato..

4 Mi Piace

Quella sensazione di familiare disagio quando leggi la descrizione della pull request citata e ti rendi conto che sei tu il colpevole…

Grazie per le istruzioni dettagliate @tshenry e @RGJ. Metterò questo in cima alla mia lista da risolvere questa settimana.

4 Mi Piace

Ok, ora ho capito meglio la situazione e ho consultato il vecchio argomento sui commenti cancellati per avere un contesto. Ho ritrovato questo messaggio di @sam, che ora ricordo:

Il caso in cui l’amministratore reimposta l’e-mail è molto diverso: in realtà si tratta di un amministratore che reimposta sia l’e-mail che la password. Se l’utente avesse accesso all’account, potrebbe farlo tutto autonomamente tramite self-service.

Quindi stiamo dicendo che, poiché è l’amministratore a cambiare l’e-mail, dovrebbe essere inviata un’e-mail di reset della password, perché se l’utente avesse accesso al vecchio indirizzo e-mail potrebbe semplicemente… accedere e farlo da solo? Ma l’e-mail di reset della password funge anche da conferma. Senza completare il processo di reset della password (che al momento è impossibile perché l’e-mail viene inviata al vecchio indirizzo), il nuovo indirizzo e-mail non risulta “confermato”, ed è proprio questo che fa apparire la seguente finestra modale:

Il problema per cui l’e-mail di reset della password viene inviata al vecchio indirizzo è facilmente risolvibile e ci permetterà almeno di raggiungere uno stato in cui il processo di reset può essere seguito:

Inoltre, poiché l’e-mail di reset della password viene attualmente inviata al vecchio indirizzo, quando viene confermata questa conferma valida l’indirizzo sbagliato e reimposta l’e-mail dell’utente sul vecchio valore.

Aggiornerò i messaggi rivolti all’amministratore che modifica l’e-mail, per chiarire che l’utente deve cliccare sul link contenuto nella nuova e-mail e cambiare la password affinché la modifica abbia pieno effetto (risolvendo così anche il problema dell’indirizzo e-mail errato).

4 Mi Piace

Aspetta, non ho capito.

C’è una differenza tra il fatto che un utente possa accedere alla vecchia email e il fatto che un utente richieda un reset della password per il proprio account Discourse. Il primo non implica affatto il secondo: si tratta di situazioni completamente diverse.

Un gran numero di modifiche dell’email da parte dell’amministratore avviene anche perché l’utente non sa come farlo, o perché l’amministratore deve temporaneamente rimuovere la restrizione email_editable = false.

Trovo molto confuso che un reset della password serva anche come conferma dell’email. Personalmente, non risponderei nemmeno a una richiesta di reset della password se non l’ho chiesta, e non mi renderei conto che si tratta di un passaggio di conferma necessario (e penso che non lo sia: una normale email di conferma sarebbe sufficiente?)

4 Mi Piace

Potrebbe essere correlato:

Quando uno dei miei utenti del forum prova a reimpostare la password oggi (utilizzando l’ultima versione di Discourse disponibile stamattina), riceve l’email ma poi riceve un errore cliccando sul link presente nell’email:

Riceve questo errore su più browser e non sta utilizzando un blocco pubblicità.

Quando vado alla pagina delle Preferenze del suo account e clicco su “Invia email di reimpostazione password”, ricevo anch’io un messaggio di errore:

Prima di mostrare “(errore)” accanto al pulsante, lampeggia brevemente “(invio email)”. Sembra però che nessuna email sia stata inviata. Posso confermare che le altre email del forum vengono inviate normalmente oggi.

Questa funzionalità funzionava correttamente in precedenza… sembra essersi rotta in qualche momento nell’ultima settimana.

Controlla i log degli errori di Discourse nel browser web quando hai effettuato l’accesso come amministratore; dovrebbe esserci un rapporto di errore con maggiori dettagli.

Ecco la voce di errore:

398 Eccezione del job: La sorgente di copia specificata è più grande della dimensione massima consentita per una sorgente di copia: 5368709120

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'

aws-sdk-core-3.99.1/lib/seahorse/client/request.rb:70:in `send_request'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:61:in `block in vacate_legacy_prefix'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `each'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `vacate_legacy_prefix'

/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'

/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'

/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'

rails_multisite-2.5.0/lib/rails_multisite/connection_management.rb:76:in `with_connection'

/var/www/discourse/app/jobs/base.rb:221:in `block in perform'

/var/www/discourse/app/jobs/base.rb:217:in `each'

/var/www/discourse/app/jobs/base.rb:217:in `perform'

sidekiq-6.1.2/lib/sidekiq/processor.rb:196:in `execute_job'

sidekiq-6.1.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'

/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'

sidekiq-6.1.2/lib/sidekiq/processor.rb:163:in `block in process'

sidekiq-6.1.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:111:in `local'

sidekiq-6.1.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'

sidekiq-6.1.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/processor.rb:257:in `stats'

sidekiq-6.1.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:13:in `call'

sidekiq-6.1.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:78:in `global'

sidekiq-6.1.2/lib/sidekiq/processor.rb:124:in `block in dispatch'

sidekiq-6.1.2/lib/sidekiq/logger.rb:10:in `with'

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:33:in `prepare'

sidekiq-6.1.2/lib/sidekiq/processor.rb:123:in `dispatch'

sidekiq-6.1.2/lib/sidekiq/processor.rb:162:in `process'

sidekiq-6.1.2/lib/sidekiq/processor.rb:78:in `process_one'

sidekiq-6.1.2/lib/sidekiq/processor.rb:68:in `run'

sidekiq-6.1.2/lib/sidekiq/util.rb:15:in `watchdog'

sidekiq-6.1.2/lib/sidekiq/util.rb:24:in `block in safe_thread'
1 Mi Piace

No, non c’entra assolutamente nulla.
Prova a cancellare i log e a forzare il verificarsi di questo errore, quindi controlla di nuovo i log.

In tal caso, i log rimangono vuoti dopo il verificarsi dell’errore.

Capisco il tuo punto di vista; per me ieri l’idea di usare il reset della password come conferma mi ha confuso. Penso che questa potrebbe essere un’opzione secondaria per l’amministratore quando cambia l’email di un utente: spuntare una casella che dice “Resetta anche la password dell’utente”. Intendo unire la PR che ho preparato per una correzione così com’è, perché il processo è attualmente completamente rotto.

Vorrei che @sam si esprimesse su un nuovo processo/flusso, dato che Sam ha originariamente parlato delle ragioni alla base del flusso di reset della password:

  1. L’amministratore modifica l’email dell’utente. Ha la possibilità di resettare la password nello stesso momento.
  2. L’utente riceve un’email al nuovo indirizzo che chiede conferma per il cambio dell’email.
    • Se risponde Sì, allora si cambia l’email. Inviamo un’email al vecchio indirizzo che comunica che l’email è stata cambiata.
    • Se risponde No, non facciamo nulla.
  3. Se l’amministratore ha specificato di voler effettuare un reset al punto 1., non appena l’utente conferma il cambio dell’email, riceve un’email per il reset della password al nuovo indirizzo.

Penso che questo sarebbe molto più chiaro, e il reset della password non avrebbe nulla a che fare con la conferma del cambio dell’email.

2 Mi Piace

Sì, non vedo perché queste due cose dovrebbero essere correlate in alcun modo?

1 Mi Piace

Vedo una bella nuova commit unita che farà piacere a tutti :smiley:

3 Mi Piace

Grazie, questo servirà solo a fondere una correzione per lo stato “completamente rotto” delle cose. Un altro PR seguirà!

È stato fatto in questo modo a seguito delle discussioni nel topic precedente con Sam. Procederò con il nuovo processo per chiarire la confusione ed eliminare il collegamento tra cose non correlate.

4 Mi Piace

Ho appena unito questa PR che esegue quanto segue:

  • Modifica il flusso di cambio email per gli utenti nell’area amministrativa in modo che l’utente riceva un’email per confermare la modifica
  • Ora registriamo chi ha richiesto la modifica dell’email
  • Se la richiesta è stata effettuata da un amministratore e non dall’utente, lo segnaliamo nell’email inviata all’utente
  • Rendiamo anche la rotta di conferma della modifica dell’email accessibile agli utenti anonimi, in modo che possa essere cliccata dall’utente anche se non ha accesso al proprio account. Se è presente un utente connesso, verifichiamo che la conferma corrisponda all’utente corrente.

Speriamo che questo renda il processo molto più chiaro!

4 Mi Piace