Mi piacerebbe molto vedere un’opzione per aggiungere un token al link “visita l’argomento” quando gli utenti ricevono una email da Discourse, in modo che il clic sul link li faccia accedere automaticamente.
Molti client di posta basati su app, come Gmail, utilizzano una visualizzazione web per caricare i link su cui si clicca se non sono presenti cookie salvati, anche se l’utente si è precedentemente connesso. Il risultato è che gli utenti vengono bloccati dal rispondere se non hanno a portata di mano le proprie credenziali di accesso e spesso rinunciano all’idea di rispondere.
Penso che questo problema potrebbe essere risolto facilmente se fosse disponibile un’opzione per aggiungere un token che consenta l’accesso automatico, in modo che gli utenti possano rispondere immediatamente cliccando sul link. Sarebbe utile anche un’opzione aggiuntiva per impostare la durata di validità del token.
È sicuramente una soluzione creativa a un problema che io risolverei consigliando di non utilizzare la web view del client di posta, o di rispondere direttamente via email.
Non utilizzo sistemi di accesso di terze parti, ma penso che questo concetto vada un po’ contro il loro funzionamento, giusto? Se fai clic su link che portano ad altri siti con accesso tramite account social, come vengono gestiti nella web view del client di posta? I token di accesso funzionano in quello scenario?
Anche se capisco ciò che dici, penso che tu abbia già perso l’utente medio, che probabilmente non sa nemmeno qual è la differenza tra una web view e l’apertura in Safari mobile.
Molti siti adottano un approccio simile, l’idea è analoga a un “link magico” utilizzato per accedere a servizi come Slack. Invece di inserire nome utente e password, puoi richiedere un link magico inviato via email. Quando clicchi sul link magico, vieni automaticamente collegato. Il link magico è un URL tokenizzato.
Se puoi reimpostare la password tramite un link inviato alla tua email, qual è la differenza?
Nel caso in cui stessi rispondendo a questa parte:
Ciò che intendevo era: funzionano i magic link quando un utente si è registrato con un account social? Io non lo so. La tua funzionalità potrebbe entrare in conflitto con molti sistemi di accesso, quindi stavo anticipando R&S.
Scusa se non ho affrontato la questione… un sviluppatore principale di Discourse lo saprebbe meglio di me, ma nei sistemi simili su cui ho lavorato non dovrebbe essere un problema. Il tuo SSO, sia esso sociale o di altro tipo, è fondamentalmente solo uno scambio di token tra il provider del servizio SSO e Discourse. Quindi sarebbe effettivamente simile, tranne che in questo caso il tuo SSO sarebbe la tua email. Semplificando un po’, in generale immagino che dovrebbe funzionare bene.
Questo è molto specifico per iOS, giusto? L’equivalente di Android (Chrome Custom Tabs) condivide i cookie in modo predefinito, quindi questo non è un problema su Android.
Non ne sono completamente sicuro e non ho ancora avuto modo di testare su un dispositivo Android. Ma penso che vada un po’ oltre questo caso d’uso. Anche se sei su desktop e semplicemente non hai interagito con la community da un po’, questo incoraggerebbe l’interazione perché ti farebbe accedere automaticamente quando vai a rispondere.
In generale, ho disabilitato la risposta via email nella maggior parte delle istanze di Discourse che gestiamo, perché il risultato dell’analisi delle email può essere piuttosto incerto e l’interfaccia web mobile per Disqus è così eccellente… quindi quando funziona (sei già loggato), cliccare su “visita l’argomento” (potrei anche aggiungere un pulsante “rispondi ora” che apre il dialogo di risposta) è quasi fluido quanto premere rispondi nel tuo client di posta.
