Vorremmo integrare Discourse nei nostri sistemi esistenti, per eliminare la dipendenza dal nostro server Discord per il supporto. Abbiamo già il nostro sistema di account configurato e vorremmo riutilizzarlo, se possibile, per ridurre l’attrito. Tuttavia, gli indirizzi email non sono richiesti per essere univoci nel nostro caso, solo i nomi utente. Sembra che Discourse si basi sull’assunto che le email saranno globalmente univoche, il che ci impedisce di integrarci direttamente.
Ho esaminato DiscorseConnect che sembrava promettente, ma afferma:
Discourse utilizza le email per associare utenti esterni a utenti Discourse
Il che non funzionerebbe nel nostro caso, poiché più account possono (e lo fanno) utilizzare lo stesso indirizzo email.
Abbiamo quindi esaminato Discourse OAuth2 Basic che a prima vista non richiedeva un’email:
L’unico attributo obbligatorio è id
Tuttavia, in seguito menziona ancora l’inserimento manuale di un indirizzo email in seguito se non fornito dalla sorgente oauth:
Nota che ho omesso il percorso email: SoundCloud non fornisce un’email, quindi l’utente dovrà fornirla e verificarla quando si registrerà per la prima volta su Discourse
L’utilizzo di Discourse sarebbe ancora qualcosa di fattibile nel nostro caso? Avere gli utenti che forniscono manualmente un indirizzo email al momento dell’accesso a Discourse per la prima volta andrebbe bene nel nostro caso, ma solo se possiamo disabilitare la possibilità di utilizzare un indirizzo email durante il processo di accesso effettivo (richiedendo l’uso solo del nome utente e della password), poiché non possiamo associare in modo affidabile un’email a un utente univoco. Essere in grado di disabilitare completamente questo dal modulo di accesso ridurrebbe l’attrito da parte nostra, poiché non sarebbe qualcosa che supporteremmo comunque, e vorremmo impedire agli utenti persino di tentare di farlo.
Abbiamo considerato questo, ma non eravamo sicuri di come avrebbe influito sul flusso oauth o se avrebbe aggiunto attrito alla registrazione/accesso. Questo tipo di modifica sarebbe invisibile all’utente, quindi non riuscirebbe ad accedere a meno che non inserisca questo indirizzo email modificato. Anche il nostro attuale server di account non sarebbe a conoscenza di queste modifiche, quindi anche se inserissero l’email modificata non saremmo in grado di trovarla nei nostri record?
Ciò interromperebbe anche gli utenti che utilizzano già alias di posta elettronica, non è vero?
Se consentissi l’accesso tramite email (cosa che penso non sia possibile con DiscourseConnect), funzionerebbe semplicemente se gli venisse inviato un link via email.
Dovresti renderlo consapevole. Penso che questo sarebbe il primo passo.
Un’altra opzione brutta sarebbe consentire l’accesso a Discourse solo al primo utente (qualunque sia la definizione).
Un’altra soluzione brutta sarebbe forzare gli utenti sul tuo sistema a ottenere indirizzi univoci per ogni account.
Bene, sì. Ovviamente sarebbe così, ed è quello a cui sto puntando. Stavo cercando una soluzione che disabilitasse del tutto l’accesso tramite email, lasciando i login con nome utente come unico metodo. Mi andrebbe bene di fatto interrompere completamente il supporto via email (nessuna notifica via email, per esempio) fornendo email completamente false dal server OAuth. Ma questo crea attrito se la possibilità di usare un’email per accedere è ancora disponibile, poiché gli utenti tenterebbero di farlo e fallirebbero.
Ciò ci costringerebbe essenzialmente a tracciare 2 email separate per utente, il che non è desiderabile, e come menzionato da @supermathie non è nemmeno garantito che funzioni con tutti i provider, e causa comunque attrito poiché dovremmo ora informare gli utenti di questo indirizzo email specifico del forum che devono ricordare.
Sì, tecnicamente funzionerebbe. Ma per ovvie ragioni non sarebbe una soluzione reale da utilizzare, poiché bloccherebbe tutti gli altri dall’entrare mai nel forum.
Questa non è una cosa che possiamo fare per motivi tecnici. Il più ovvio è che abbiamo già utenti che hanno lo stesso indirizzo email di altri account. Ma quello più grande è che semplicemente non possiamo farlo. Il progetto in cui stiamo cercando di integrare Discourse è Pretendo Network, un progetto di emulazione del server per Nintendo Network. Nintendo ha permesso al suo sistema di account di riutilizzare gli indirizzi email, quindi per emulare accuratamente i server dobbiamo farlo anche noi. Forzare email univoche non è nei nostri piani.
Qualcuno del mio team ha suggerito di gestire il nostro server SMTP che si occupa di mappare le email false per Discourse alle email reali dei nostri utenti, inoltrando in quel modo le email inviate da Discourse. Il che funzionerebbe, ma ovviamente comporta un costo tecnico maggiore per noi e non risolve comunque il problema di disabilitare l’accesso via email e l’attrito menzionato che deriva dal nostro caso.
Sembra che potremmo dover semplicemente fare un fork di Discourse o utilizzare un’altra soluzione di forum per fare ciò di cui abbiamo bisogno.
Sto andando a memoria, ma puoi usare DiscourseConnect con indirizzi email falsi ma univoci. Se i nomi utente sono garantiti come univoci da parte tua, l’implementazione potrebbe essere piuttosto semplice. L’indirizzo email potrebbe essere impostato su qualcosa come username@invalid.com.
Gli utenti accederanno al tuo sistema con qualsiasi metodo stiano utilizzando ora. Il tuo sistema genererà quindi il payload SSO con l’indirizzo email falso.
Lo svantaggio di questo approccio è che dovrai disabilitare le email su Discourse. Ciò può essere fatto impostando l’impostazione disable emails su yes o non-staff (se i tuoi membri dello staff hanno indirizzi email univoci).
Potresti anche considerare l’utilizzo di indirizzi email basati su + per gli utenti con indirizzi email duplicati. L’ultima volta che ho controllato, Discourse considerava univoci gli indirizzi email basati su +. Assicurati solo di codificare in URL gli indirizzi email prima di utilizzarli nel payload di DiscourseConnect. Il rischio qui è che se gli utenti hanno indirizzi email duplicati e utilizzano un server di posta elettronica che non supporta gli indirizzi email basati su +, non riceveranno email da Discourse, ma ciò consentirebbe ai tuoi altri utenti di ricevere email da Discourse.
Sì, ma solo per un caso particolare. Se un utente ha creato un account Discourse prima che il sito Discourse implementasse DiscourseConnect, Discourse tenterà di associare gli utenti esistenti all’indirizzo email presente nel payload di DiscourseConnect. Se stai avviando un nuovo sito Discourse, questo non sarà un problema.
Un altro caso in cui ho visto emergere il problema di associazione delle email è quando, a causa di qualche codice difettoso sul sito del provider di autenticazione, i record SSO sul sito Discourse sono diventati corrotti. In quel caso, il sito è stato in grado di eliminare tutti i record SSO sul lato Discourse, quindi far associare a Discourse gli utenti all’indirizzo email del payload SSO la prossima volta che hanno effettuato l’accesso. Discourse ha quindi generato nuovi record SSO per gli utenti. Questo funzionerebbe ancora con indirizzi email falsi.
La logica con l’autenticazione DiscourseConnect è che Discourse tenta prima di trovare l’utente in base al campo external_id del payload, se non trova un utente, ripiega sul tentativo di trovare l’utente in base al campo email del payload, se ancora non trova un utente, genera un errore.
Verifica tutto questo prima di implementarlo effettivamente su un sito live, ma so che l’approccio dell’email falsa è stato utilizzato su siti di produzione per casi in cui gli indirizzi email reali degli utenti non possono essere condivisi con il sito Discourse.
@simon Grazie per le informazioni! Iniziamo a fare progressi.
Questo va bene, e ho già menzionato in precedenza che questa è una soluzione accettabile per il problema “tutte le email devono essere univoche”. Sono perfettamente d’accordo con la disabilitazione delle email nel nostro caso e l’uso di email fittizie è stata una soluzione a cui sono arrivato prima di pubblicare questo post.
Forse non sono stato chiaro all’inizio, ma il punto del post era vedere se fosse possibile forzare il prompt di accesso ad accettare solo i nomi utente, poiché attualmente l’accesso può essere effettuato sia tramite nome utente che tramite email. Se gli accessi tramite email sono ancora visualizzati come disponibili nel prompt di accesso su Discourse, i nostri utenti potrebbero tentare di utilizzare l’indirizzo email del loro account esistente e incontrare un errore. Quindi, o dovremmo semplicemente gestire le persone che tentano, e falliscono, di utilizzare il loro indirizzo email attuale o in qualche modo informare l’utente del suo nuovo indirizzo email specifico del forum. Entrambe le cose possono causare confusione e attrito per gli utenti, quindi idealmente potremmo semplicemente limitare il prompt di accesso ad accettare solo i nomi utente.
Anche lo staff che ha indirizzi email univoci non è purtroppo garantito, quindi non vorrei fare affidamento su questo. Questa impostazione disabilita solo l’invio di email? O disabilita l’uso delle email nel suo complesso, come quello che sto cercando per il prompt di accesso?
Ho esaminato la pagina di DiscourseConnect più volte e non ho visto questa opzione lì. C’è forse un posto migliore per vedere questo tipo di documentazione? Non ho visto alcun link a una documentazione completa in quel post, quindi ho solo presunto che tutte le informazioni lì fossero tutto ciò che c’era.
Ammetto di non aver effettivamente configurato DiscourseConnect per approfondire le impostazioni. Speravo che la documentazione fosse sufficiente per capire cosa si può e cosa non si può fare, in modo da non dover configurare un’intera istanza di test del forum a meno che non fossimo sicuri di impegnarci. Ma sembra che ci siano ancora alcune informazioni non facilmente disponibili, a meno che non mi sia perso qualcosa di ovvio?
Anche questo è stato considerato in precedenza in questo thread, ma il problema rimane che dovremmo o gestire gli accessi email falliti o informare l’utente di questo nuovo indirizzo email del forum. Rimuovere questo attrito era il mio obiettivo principale. Se non è possibile farlo qui senza fare un fork di Discourse stesso, e l’unica soluzione è o gestire gli accessi email falliti o dare alle persone un nuovo indirizzo email da ricordare, allora potremmo stare meglio con una soluzione di forum diversa.
Mi sembra di aver capito male, non è molto chiaro dal post stesso. Tuttavia, il mio punto nel sollevare questo era illustrare la dipendenza dall’unicità delle email, che sarebbe comunque un problema.
Questo DEFINITIVAMENTE non era chiaro dal solo post, a meno che non mi sia perso qualcosa. Grazie per quella chiarificazione! Suona più in linea con quello che speravo.
Per quanto ne so, non è possibile forzare il prompt di accesso di Discourse ad accettare solo il campo del nome utente. Saresti anche bloccato nel cercare di capire come far registrare gli utenti in primo luogo. Ecco perché suggerisco DiscourseConnect.
Quando DiscourseConnect è abilitato, diventa l’unico sistema di autenticazione per il tuo sito Discourse. Quando gli utenti fanno clic sul pulsante di accesso su Discourse, vengono automaticamente reindirizzati all’URL che hai aggiunto all’impostazione del sito discourse_connect_url. Il tuo sistema di autenticazione si occuperà del resto. Ciò significa che se hai un sito a cui gli utenti possono attualmente accedere con nome utente e password, continueranno ad accedere in quel modo.
Se non è possibile aggiungere codice al tuo sito attuale, potresti anche creare un piccolo sito web a cui gli utenti possono accedere con nomi utente e password, quindi aggiungere il codice DiscourseConnect a quel sito. Sarebbe meno lavoro che fare un fork di Discourse.
Grazie! Sembra che avessi un’errata comprensione fondamentale di DiscourseConnect. Credevo che la pagina di accesso rimanesse su Discourse e che si limitasse a contattare il server esterno. Non ero a conoscenza del fatto che l’utente venisse reindirizzato a una pagina di accesso diversa, a nostra completa scelta.
La mia errata comprensione di DiscourseConnect sembra essere stata il fulcro di questo problema e di tutta la confusione.
Se non ti interessa che Discourse invii email per le notifiche, potresti far sì che il tuo SSO fornisca a Discourse l’indirizzo email game-username@bogus.invalid.
Potrebbe quindi essere possibile per gli utenti aggiungere un secondo indirizzo email reale e quindi passare quello fasullo a quello secondario.
Non l’avevo fatto. Come ho detto prima, non volevamo procedere con un’implementazione di test finché non avessimo saputo che Discourse era utilizzabile. Quindi non avevo provato nulla, finora abbiamo solo letto le tue funzionalità e chiesto qui quando le cose non erano chiare. È fantastico sentirlo, non ero a conoscenza del fatto che potessimo controllare le cose a quel livello
Onestamente, sembra piuttosto difficile trovare una documentazione reale su qualsiasi cosa al di fuori dell’API. Almeno dal punto di vista di un utente alle prime armi.
Non c’è nulla di ovvio sulla homepage di Discourse che rimandi a una documentazione, e tutti i link sulla pagina DiscourseConnect rimandano a pagine non correlate o allo stesso post. Tentare di cercare “Discourse documentation” sui motori di ricerca porta solo a pagine come Documentation - Discourse Meta, che è solo la categoria del forum per essa, non una vera pagina di documentazione, e https://docs.discourse.org/ ma questa è la documentazione dell’API e non contiene nulla riguardo a funzionalità come DiscourseConnect, a quanto pare.
Tentare di trovare organicamente queste informazioni si è rivelato difficile.
C’è qualche posto ovvio che ho semplicemente perso dove tutto questo viene spiegato? Sembra che la cosa più vicina che riesco a trovare sia la categoria del forum, poiché ci sono molte guide/how-to scritte dallo staff e simili su vari argomenti. Ma riutilizzare il forum per documentare se stesso non mi sembrava giusto? Non esiste una fonte di documentazione dedicata per le funzionalità/strumenti di Discourse come per l’API di Discourse?
Corretto, funzionerebbe. Come affermato più volte, l’utilizzo di un’email fasulla dal provider oauth è qualcosa a cui siamo arrivati prima ancora di pubblicare questo post.
Ma ciò da solo non risolve il problema “se un utente vede nel prompt di accesso che le email sono accettate, proverà a usarle e fallirà a causa di un’email fasulla”.
Tuttavia, ho appena frainteso il funzionamento di DiscourseConnect. Avevo l’impressione che il modulo di accesso fosse ancora su Discourse e che Discourse semplicemente contattasse il provider oauth. @simon me l’ha corretto ora, non ero a conoscenza che spostasse fisicamente l’utente fuori dal sito verso il nostro modulo di accesso. Questo da solo risolve praticamente tutti i problemi che avevo. Grazie, comunque!
Anche se vuoi solo “dare un’occhiata” e non hai intenzione di continuare a utilizzare il nostro hosting, sentiti libero di avviare un sito di prova! Non ci dispiace!
Grazie per questo feedback: stiamo compiendo uno sforzo consapevole per migliorarlo.
Ti dispiacerebbe se ti contattassimo per discutere ulteriormente?
Nessuna delle persone con cui ho lavorato è stata insoddisfatta dell’hosting di discourse.org. Se hai bisogno di auto-ospitare per qualche motivo, puoi accedere a https://dashboard.literatecomputing.com/ e unirti al gruppo “free trial” e usare la Dashboard gratuitamente (se non riesci a capire come unirti al gruppo di prova gratuita, probabilmente avrai bisogno di più supporto di quanto io sia disposto a dare). Se sei disposto a usare Digital Ocean e mailgun, devi solo inserire le chiavi API e un nome host.
Per imbarazzo, non avevo nemmeno pensato a questa opzione! È un buon punto e probabilmente la utilizzeremo per scopi di test.
Avevo già esaminato le vostre opzioni di hosting oggi, poiché sarebbe più facile che l’auto-hosting, ma purtroppo sembra essere fuori dal nostro budget. Abbiamo oltre 200.000 utenti, quindi il piano “Basic” non è un’opzione. Abbiamo più di 5 dipendenti, quindi il piano “Standard” non è un’opzione. E come progetto FOSS operiamo con donazioni, e riusciamo a malapena a coprire le spese per tenere le luci accese e pagare un singolo sviluppatore a tempo pieno, quindi il piano “Business” è irraggiungibile.
Utilizzare la prova per scopi di test è comunque un’idea fantastica, grazie! Comunque, auto-ospitiamo già la maggior parte dei nostri servizi, anche la nostra istanza Mastodon, quindi l’auto-hosting di Discourse non è un grosso ostacolo.
Certamente! Sono sempre felice di aiutare se posso, anche solo dando un feedback. Spero di non essere sembrato troppo negativo, perché non era mia intenzione, sia chiaro.
Se sei interessato, offriamo hosting gratuito per alcuni progetti FOSS… i tuoi numeri di staff sono superiori ai nostri limiti, ma le persone che prendono la decisione potrebbero essere in grado di far passare la cosa.
(nota che la nostra definizione di “staff” qui è “Amministratori” + “Moderatori a livello di sito”, non “staff della rispettiva azienda” - sarei curioso di sapere quale fosse la definizione di staff nella tua testa prima di questo)
Grazie! Mi era sfuggito questo sulla tua pagina dei prezzi. Sono tornato indietro a ricontrollare ed è sepolto in fondo alla pagina Darò un’occhiata e ne parlerò con la mia gente!
La nostra definizione di “staff” in questo caso copre 2 ruoli ampi:
Persone del nostro team di sviluppo principale (come progetto open source questo può fluttuare, poiché le persone possono andare e venire, ma abbiamo avuto circa 5-10 sviluppatori attivi nel corso degli anni in qualsiasi momento)
Il nostro team di moderazione (non sviluppatori e membri della comunità che moderano i nostri servizi, come le partite online e la nostra implementazione Miiverse, nonché il nostro server Discord). Anche questo varia
POTREMMO limitarlo a soli 5 dei nostri sviluppatori, il che rientrerebbe nei limiti, ma richiederebbe a noi di decidere chi ha e chi non ha pieni diritti sul forum. Limiterebbe anche il numero di persone in grado di moderare i forum (abbiamo introdotto un team di moderazione esterno al team di sviluppo per alleggerire questo carico solo su di noi in primo luogo)
Lo solleverò sicuramente con le persone dalla mia parte e vedremo come vanno le cose!
Darò un’occhiata e ne parlerò con la mia gente!