Come posso confermare automaticamente un indirizzo email secondario?

Supporto
1

Ho visto alcuni argomenti toccare questo problema, ma nulla sembra affrontarlo.

In sostanza, la nostra azienda è stata acquistata. Ciò significa che tutti gli utenti passeranno da @old_company.com a @new_company.com

Ho una mappa degli indirizzi email vecchi e nuovi. Quello che vorrei fare è aggiungere l’indirizzo email @new_company.com per un utente e confermarlo automaticamente. Altrimenti, dovranno passare attraverso le email di conferma da soli, il che realisticamente non accadrà.

C’è un modo per aggiungere un’email secondaria come amministratore e confermarla automaticamente?

Simon menziona quanto segue

Ma non mi è chiaro come funzioni. Come può sincronizzare un indirizzo email con un account, se l’indirizzo non è ancora stato confermato? Ciò significa che dovrei/potrei

  1. aggiungere un’email secondaria per l’utente tramite API
  2. (forse) disabilitare l’invio di email in uscita per 10 minuti in modo che non venga inviata alcuna email di conferma
  3. abilitare saml sync email
  4. gli account utente si confermano e si aggiornano quando accedono con SAML

Nota, in questo esempio stiamo anche cambiando il provider SAML

Anche se l’email secondaria non è stata confermata, la configurazione di cui sopra significa che quando tenteranno di accedere con quell’email per la prima volta, questa verrà automaticamente confermata e collegata all’account?

2 Mi Piace
4

image

Solo come nota, un problema che ho frainteso è stata l’email di conferma. Come amministratore ricevi due email, una per confermare la tua vecchia email, poi una seconda per confermare la modifica.

Ho presunto che questo si applicasse a tutti gli utenti, ma con l’impostazione nell’immagine sopra, puoi impostarla per applicarla solo al personale. Ciò significa che gli utenti riceverebbero una sola email per confermare la modifica.

Devo ancora capire come confermare automaticamente l’email per l’utente :thinking:

1 Mi Piace
5

Non sono sicuro che ci sia un modo per confermare automaticamente tramite l’interfaccia utente/API. :thinking: Penso che se c’è l’SSO, la conferma dell’email/identità sia gestita da loro? In tal caso, l’uso di sso_sync importerebbe i dati/l’email già confermati e li utilizzerebbe come “affidabili”.

Un po’ di fact-checking dopo… :slight_smile:

/admin/users/sync_sso è solo per DiscourseConnect. Penso che tu lo sapessi già, ma lo dico ad alta voce per chiunque legga questo in seguito.

Ma c’è anche l’impostazione admin auth_overrides_emails che potrebbe essere utile per questo.

Essenzialmente, se il tuo provider SAML sta inviando un’email verificata e auth_overrides_emails è impostato, Discourse inizierà a utilizzare la nuova email senza inviare alcuna conferma. :+1:

2 Mi Piace
9

Questa non è una risposta diretta alla tua domanda, ma: Nel caso di ridenominazione di massa di indirizzi email, potresti farlo tramite la console rails:

o = "@old_company.com"
n = "@new_company.com"
UserEmail.where("email LIKE ?", "%#{o}").each do |ue|
  ue.email.sub!(o, n)
  ue.save!
end

Se preferisci aggiungere un indirizzo email secondario:

o = "@old_company.com"
n = "@new_company.com"

UserEmail.where("email LIKE ?", "%#{o}").each do |ue|
  sm = UserEmail.new
  sm.user_id = ue.id
  sm.email = ue.email.sub!(o, n)
  sm.save!
end
1 Mi Piace
10

Grazie per i suggerimenti. Ci ho provato nel modo seguente:

1. Aggiungere un’e-mail secondaria all’utente tramite API

L’e-mail non è confermata, ma è collegata all’account

image
image577×304 14.7 KB

2. Configurare le seguenti impostazioni:

image

image

image

  • Ho dimenticato di impostare saml sync su true, tuttavia non credo che ciò avrebbe influito sull’esito. Il problema sembra ancora essere un conflitto in termini di conferma dell’e-mail.

3. Risultato

Il risultato è stato la creazione di un nuovo account utente basato sulla nuova e-mail aziendale. Nel peggiore dei casi potrei unirli, ma è davvero un caso peggiore.

Posso ancora vedere l’e-mail non confermata nel vecchio account. Provo a inviare nuovamente la conferma solo per vedere cosa succede, ma ricevo un errore 403 (Forbidden).

Sembra che l’e-mail debba essere confermata prima di poterla sincronizzare :confused:

A meno che non mi stia sfuggendo qualcosa, sembra che abbia bisogno di un modo per confermare la seconda e-mail.

Mi chiedo se questo abbia ancora lo stesso problema in termini di conferma, o se siano considerate confermate? Una complicazione aggiuntiva è che anche la parte utente di user@company.com è cambiata. Ma sospetto che ciò significherebbe che dovremmo eseguire un CSV di mappature tra i vecchi e i nuovi indirizzi e-mail.

11

Stavo pensando più di cambiare l’email nell’SSO, abilitando auth overrides emails, e poi accedere al tuo account tramite il tuo SSO come al solito.

Potrei starmi perdendo qualcosa.

1 Mi Piace
12

Penso che potrebbe fare questo, in quanto convalida un account SAML in base all’indirizzo email e al server SAML utilizzati per accedere. Il problema è che si tratta di un SAML IDP completamente diverso (Nuova Azienda).

Di conseguenza, sovrascrive/crea correttamente l’email per essere l’email SAML, ma lo fa per un account nuovo di zecca perché l’account Discourse non è associato al nuovo indirizzo email.

Tuttavia, se l’account esistente ha già l’indirizzo email SAML nuovo confermato in Discourse, allora l’accesso è fluido e diventa la loro nuova email di accesso SAML.

13

Hmmm. :thinking: Penso di aver lavorato sull’ipotesi che il passaggio al nuovo IDP li avrebbe mappati in base a un ID esterno di qualche tipo.

Penso sia possibile attivare/confermare l’email tramite la console rails aggiungendo anche le informazioni del token. Qualcosa come:

old_domain = "<insert_here_the_old_domain>"
new_domain = "<insert_here_the_new_domain>"

users = UserEmail.where("email like '%" + old_domain + "'")

users.each do |user_email|
    user = User.find_by_id(user_email.user_id)
    user.email = user.email.gsub(old_domain, new_domain)
    user.email_tokens.create(email: user.email)
    user.activate
    user.save!
    puts "."
end
2 Mi Piace
14

Per quanto ne so, ciò non è accaduto. Per un’altra piattaforma abbiamo dovuto ottenere noi stessi un elenco di email ed eseguire la mappatura.

Sembra sempre più che questa sia la strada da percorrere. Siamo ospitati da voi, quindi lo comunicherò al nostro CSM e seguirò questo argomento con eventuali progressi.

2 Mi Piace