Registrazione più semplice con codici via e-mail

[rishabh]

Le community Discourse possono ora consentire agli utenti di accedere utilizzando un codice breve inviato via e-mail, al posto di un link magico. Questo offre un flusso di accesso senza password, familiare a molte altre piattaforme SaaS, e funziona in concomitanza con la tua configurazione esistente per l’autenticazione a due fattori.

In questo argomento, esamineremo le modifiche principali e condivideremo come puoi iniziare a utilizzarle fin da subito.

Cosa è cambiato

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

:

1. Inseriscono un indirizzo e-mail e fanno clic 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), appare 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 usa e getta nella tua community

Per il momento, questa è considerata una modifica sperimentale! Prima di diffonderla più ampiamente, accogliamo il tuo feedback per aiutarci a migliorare.

Per attivarla, vai alla pagina Modifiche in arrivo nella tua area di amministrazione (/admin/config/upcoming-changes) e trova l’elemento Abilita accessi locali tramite codice. Aggiorna il campo Abilitato per… per iscrivere il tuo sito a questo nuovo design:

Prima di abilitare, conferma che sia enable_local_logins sia enable_local_logins_via_email siano anche 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 per i nuovi account

I nuovi membri che si registrano senza un nome utente riconoscibile nel loro indirizzo e-mail ricevono ora un nome generato amichevole come “QuietFalcon42” al posto di un segnaposto generico come user1. Il passaggio “account pronto” precompila la proposta e include un pulsante a dado per generarne una nuova.

Le liste di parole dietro le proposte 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 e mantenere il vecchio fallback numerico, disabilita enable_random_usernames.

Cosa ne pensi?

Ora tocca a te: ci piacerebbe molto sapere cosa pensi di questa nuova funzionalità. Cosa ti piace e cosa no; 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 piuttosto sicuri del fatto che qui serva una password, ma dovrebbe chiedere l’indirizzo e-mail. Così i miei telefoni e simili saprebbero di dover suggerire un indirizzo e-mail anziché altre credenziali.