Registrazione più semplice con codici via email

[rishabh]

Le comunità Discourse possono ora consentire agli utenti di accedere utilizzando un breve codice inviato via e-mail anziché un link magico, offrendo un flusso di accesso senza password che risulta familiare a molte altre piattaforme SaaS e che funziona in combinazione con la configurazione di autenticazione a due fattori esistente.

In questo argomento, esamineremo le principali modifiche e condivideremo come puoi iniziare a utilizzarle oggi stesso.

Cosa è cambiato

Quando questa funzionalità è abilitata, i membri vedono un flusso più semplice:

:

1. Inseriscono un indirizzo e-mail e cliccano su Continua.
2. Un codice a sei cifre arriva nella loro casella di posta. Lo incollano (o lo digitano) e il modulo si invia automaticamente quando viene inserito l’ultimo numero.
3. Se hanno l’autenticazione a due fattori abilitata (TOTP, codici di backup o chiave di sicurezza), viene visualizzato successivamente il passaggio standard di 2FA.

Alcuni dettagli da tenere a mente: i codici sono validi per 10 minuti, scadono dopo 5 tentativi falliti e possono essere utilizzati solo una volta.

Attivazione dei codici di accesso monouso nella tua comunità

Per ora, questa è considerata una modifica sperimentale! Prima di diffonderla più ampiamente, accogliamo con favore il vostro feedback per aiutarci a migliorare.

Per attivarla, vai alla pagina Modifiche imminenti nella tua area di amministrazione (/admin/config/upcoming-changes) e trova la voce Abilita accessi locali tramite codice. Aggiorna il campo Abilitato per… per optare il tuo sito per questo nuovo design:

Prima di abilitare, verifica che sia enable_local_logins che enable_local_logins_via_email siano impostati su true, poiché la funzionalità non può essere attivata senza di essi. Se stai utilizzando DiscourseConnect (enable_discourse_connect), questa funzionalità non può essere abilitata.

Una volta abilitata la modifica, il percorso di accesso tramite codice appare automaticamente.

Nomi utente casuali opzionali per i nuovi account

Puoi assegnare ai nuovi membri che si registrano senza un nome utente riconoscibile nella loro e-mail un nome generato amichevole come “QuietFalcon42” anziché un segnaposto generico come user1.

Se clicchi su Mostra impostazioni correlate per questa modifica imminente e abiliti l’impostazione del sito enable_random_usernames, il passaggio di preparazione dell’account precompila la suggerimento e include un pulsante a dado per generarne uno nuovo:

Le liste di parole dietro i suggerimenti sono configurabili tramite le impostazioni del sito random_username_adjectives e random_username_nouns, in modo che le comunità possano adattarle al loro tono o alla loro lingua.

Cosa ne pensate?

Ora tocca a voi: ci piacerebbe molto sapere cosa pensate di questa nuova funzionalità. Cosa vi piace e cosa non vi piace; cosa funziona bene e cosa potrebbe essere migliorato?

[darkpixlz (Pyx)]

Ho appena provato sul mio sito. Non so cosa pensino gli altri, ma a me, come utente di un gestore di password, sembra un bel passo indietro…

Questa nuova procedura elimina la strategia attuale “genera email, inserisci nome utente, genera password, salva” in cui il mio gestore di password mi ha abituato, e ti obbliga a inserire l’email prima di tutto il resto. Non ho problemi con la cosa del codice via email (anzi, la preferisco quasi, soprattutto se il codice è incluso nell’oggetto dell’email), ma mi oppongo fermamente alla rimozione degli altri campi dei dati dell’account. Se fossi un utente senza alcuna competenza tecnica, immagino che anch’io non darei la mia email a una casella senza alcuna informazione, come questa, perché non è un design comune. Prima che questa modifica diventi permanente, sarebbe fantastico se si potessero ripristinare i campi rimossi.

[dfabulich (Dan Fabulich)]

I codici via email, noti anche come “magic link”, sono discreti, ma incentivare gli utenti a utilizzare i passkey migliora notevolmente l’esperienza.

Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over

Uno dei problemi più grandi con i codici via email è che non funzionano come ci si aspetterebbe nei browser in-app, incluso il browser in-app di Gmail.

Probabilmente il problema più comune che le persone incontrano con i magic link è che pensano di aver effettuato l’accesso al sito nel loro browser normale, ma in realtà si sono connesse tramite un browser in-app. Ad esempio, qualcuno potrebbe ricevere il link di accesso nella propria email. Apre l’app Gmail, clicca sul pulsante “Accedi a 404 Media” e il telefono carica la pagina web. Ma questo sta caricando il sito web nel browser web di Gmail, non nel tuo Safari nativo.

I passkey risolvono questo problema.

Per iniziare, i siti web che utilizzano magic link possono rendere i passkey una funzione opzionale e attivabile volontariamente per i clienti che si sono lamentati di come funzionano oggi i loro magic link. Per assicurarsi che non causino problemi, come una sorta di lancio morbido, potrebbero rendere la funzione completamente opzionale.

Poco dopo, una volta che le persone che gestiscono il sito web sono convinte che i passkey aiutano davvero a risolvere i problemi di esperienza utente legati ai magic link, possono invitare gli utenti ad aggiungere i passkey dopo l’accesso, una volta ogni 90 giorni circa, o ogni volta che effettuano l’accesso utilizzando la funzione di accesso cross-device dei passkey. La formulazione di un tale prompt potrebbe essere qualcosa del genere per gli utenti su dispositivi Apple: Vuoi evitare di dover controllare la tua email la prossima volta? Configura un passkey per utilizzare Face ID o Touch ID per accedere rapidamente e in modo sicuro.

Incentivare gli utenti a utilizzare i passkey è lo stesso che incentivare gli utenti a utilizzare un gestore di password, perché i passkey sono semplicemente password che richiedono un gestore di password.

[Don]

Ciao

Mi piace molto questo approccio! Tuttavia, mi preoccupa un po’ il fatto che il nome visualizzato non possa essere modificato prima che la registrazione sia completata. Penso che sarebbe fantastico aggiungere un’opzione per modificarlo durante il processo.

Nella mia comunità, ho disabilitato l’impostazione del sito Prioritize username in UX, il che significa che il Nome Completo/Nome Visualizzato è prioritario in tutta l’interfaccia utente. Per questo motivo, i nomi assegnati automaticamente come “user21” hanno un aspetto piuttosto brutto sul front-end se l’utente non ha un’opzione immediata per personalizzarli.

Grazie!

[pmusaraj (Penar Musaraj)]

@dfabulich

Uno dei problemi più grandi dei codici via email è che non funzionano come ci si aspetterebbe nei browser in-app, incluso quello di Gmail.

Questo nuovo flusso non invia un link magico. Invia solo il codice. L’utente rimane sulla stessa pagina e copia/incolla il codice dalla sua email nel modulo di registrazione. Quindi questo nuovo approccio aiuta effettivamente con i browser in-app (è uno dei principali vantaggi del cambiamento).

@dfabulich

Incoraggiare gli utenti verso le chiavi di accesso

Questa è certamente qualcosa che ci piacerebbe fare successivamente, nella fase di inserimento della password durante la registrazione. Le app e i siti web hanno aumentato il supporto per le chiavi di accesso, continuo a vedere suggerimenti per le chiavi di accesso in molti contesti, quindi ha senso aggiungerle anche a Discourse. (Una massa critica di supporto è molto utile in questo passaggio dalle password alle chiavi di accesso.)

[DomMcD (Dominic McDevitt)]

L’unico problema che ho con questa funzione è che rimuove i campi per il nome e il nome utente dalla mia pagina di registrazione. È intenzionale? Non voglio costringere gli utenti a perdersi tra le impostazioni subito dopo la registrazione solo per impostare un nome utente che non sia “user63”.

[kddkd (16)]

Questo metodo di registrazione con codice di verifica via email è il cambiamento che ho sempre desiderato!

[Moin]

Senza questa modifica, il link “Ho dimenticato la password” e il link “Inviami un’email” avevano la stessa dimensione. Ora il secondo è più grande. È intenzionale?

[Moin]

È stato corretto in

UX: Match font size of one-time code login link (#41879)

[rishabh]

Grazie per il feedback, sì, è intenzionale come parte di un metodo più veloce per creare account.

@DomMcD

Non voglio costringere gli utenti a frugare tra le impostazioni subito dopo la registrazione solo per impostare un nome utente che non sia “user63”.

Prendiamo nota, sì, stiamo esplorando idee per semplificare questo passaggio successivo o per impostare i nomi utente iniziali utilizzando un metodo diverso.

[Moin]

Sono d’accordo. Quei nomi utente generici rendono l’interazione con gli utenti più confusa. Poiché gli utenti hanno di default solo 3 giorni per aggiornare i nomi, mi aspetto che spesso se ne accorgano solo dopo che questo periodo è scaduto, quindi lo staff deve occuparsi di rinominarli.
Ho apprezzato molto il fatto che Offering blank username suggestions rather than ‘UserN’ at signup abbia impedito che ciò accadesse, ad esempio qui su meta. L’ultimo utente userXXX è stato creato il 7 gennaio, prima che quella correzione venisse integrata. Poi non ci sono stati nuovi userXXX fino all’attivazione di questa funzione, e da allora ne sono stati creati 12 nuovi.

[Thomas_Rother (Thommie Rother)]

Questa funzionalità è estremamente utile. Sempre più piattaforme stanno utilizzando la funzione “codice monouso via email” per offrire accessi sicuri con MFA, senza la necessità di avere a disposizione un dispositivo specifico (con l’autenticatore appropriato).

[rishabh]

@DomMcD

Non voglio costringere gli utenti a frugare tra le impostazioni subito dopo la registrazione solo per impostare un nome utente che non sia “user63”.

@Moin

Sono d’accordo. Quei nomi utente generici rendono l’interazione con gli utenti più confusa. Dato che gli utenti hanno di default solo 3 giorni per aggiornare i nomi, mi aspetto che spesso se ne accorgano solo dopo che quel tempo è trascorso, quindi il personale dovrà occuparsi di rinominarli.

Non stai vedendo questo passaggio durante la creazione dell’account?

[Moin]

Questa è una citazione strana: sembra che DomMcD mi abbia citato, il che non è vero.

Non ho testato i passaggi. Stavo commentando ciò che ho notato riguardo ai nuovi utenti qui su Meta. Non importa se vedo un campo durante la registrazione. Devo fare i conti con ciò che gli altri fanno con quel campo.

Mi chiedo anche come vengano gestiti i nomi. Sebbene non tutti gli utenti sembrino utilizzare gli username generati, noto ancora di più quelli che hanno un nome del tipo userXXX.

Sembra che ottengano questo anche quando cambiano l’username, e ciò fa sì che lo stesso numero venga utilizzato di nuovo e di nuovo finché l’username non è già in uso, e poi si ricomincia con il numero successivo.

Ad esempio, 0102100988082, mohamedasarudeen e user603 hanno tutti user603 come loro nome.

So che potrebbero cambiare il nome, ma di nuovo, non posso cambiare la mia esperienza nell’interagire con loro.

[rishabh]

Grazie a tutti per le segnalazioni, una correzione verrà integrata molto presto:

FIX: Stop placeholder usernames sticking after email code signup (#42796)

[rishabh]

Aggiornamento

Grazie all’ultimo lavoro di @keegan, disponiamo ora di una funzione di generazione dei nomi utente in questa fase che precompila una suggerimento:

@rishabh

Nomi utente casuali per i nuovi account

I nuovi membri che si iscrivono senza un nome utente riconoscibile nella loro email ora ricevono un nome generato amichevole come “QuietFalcon42” anziché un segnaposto generico come user1. La fase di preparazione dell’account precompila il suggerimento e include un pulsante con un dado per generarne uno nuovo.

Le liste di parole alla base dei suggerimenti sono configurabili tramite le impostazioni di sito random_username_adjectives e random_username_nouns, in modo che le community possano adattarle al proprio tono o alla propria lingua. Per disattivare la funzione e mantenere il vecchio fallback numerico, disabilita enable_random_usernames.

[Jagster (Jakke Flemming)]

Una richiesta un po’ UX, se possibile. Questa:

I miei dispositivi sono abbastanza sicuri che qui serva una password, ma dovrebbe chiedere l’email. Così i miei telefoni e altri dispositivi saprebbero di dover offrire un indirizzo email invece di altre credenziali.

[thisisjoshjones (Joshua Jones)]

È possibile implementare anche nella landing page degli inviti questo flusso di registrazione? Sono certo che si tratti di qualcosa che va oltre l’ambito di questa fase alfa, ma tale implementazione sarebbe molto utile una volta che la funzionalità sarà stabile. Questo riduce davvero la barriera all’ingresso per i membri della mia community, quindi grazie!

[mcwumbly (Dave McClure)]

Per coincidenza, in questo momento è in corso del lavoro in tal senso:

https://github.com/discourse/discourse/pull/43138

[ecki (Bernd)]

In generale mi piace questa funzione (il primo passo di registrazione con solo email e codice), ma ha qualche imperfezione:

a) login e registrazione dovrebbero essere configurazioni separate
b) nascondere il campo nome utente nel modulo di registrazione dovrebbe essere un’opzione aggiuntiva, dato che i nomi utente sono ancora una funzione di comunicazione importante; nomi utente casuali o basati su contatori sembrano piuttosto strani
c) stranamente, i nomi utente casuali hanno funzionato sul mio sito per alcune registrazioni di spam (utenti non verificati), ma non per due utenti reali: entrambi hanno ricevuto “user1” e “user2” come nomi, che fastidio. (Non sono sicuro di quale sia la differenza tra gli spammer e gli utenti)
d) per il login, potrebbe essere un pulsante aggiuntivo, magari uno che invia un’email con un link magico e un codice. Non vedo la necessità di separarli
e) la documentazione dovrebbe chiarire che rimuove il campo nome utente (o meglio, che non lo rimuove)