È esattamente quello che avevo in mente anche io.
Includerò il link all’argomento Category Group Review/Moderation poiché inizialmente ho avuto difficoltà a trovarlo tramite la ricerca.
Ho sempre difficoltà a trovare la Documentation nella categoria Announcements
2 Mi Piace
Onestamente, questa è probabilmente una buona idea a prescindere, gli amministratori hanno TUTTI i diritti (scaricare backup, vedere/modificare segreti di configurazione, vedere i dati personali delle persone, accedere ai messaggi personali, …) ed è meglio mantenere questo cerchio ristretto.
C’è molto spazio per i “privilegi elevati” senza essere amministratori a pieno titolo.
2 Mi Piace
Grazie a entrambi per questo, non ero a conoscenza che fosse una cosa separata!
Grazie per questa chiarificazione, non ero a conoscenza che fosse così. Hai ragione, lo limiteremmo sicuramente comunque ora che lo so.
Ho esaminato i limiti/requisiti di questo e l’ho trasmesso al mio team. Purtroppo sembra che dovremo comunque auto-ospitare. L’hosting FOSS che offrite è molto generoso, semplicemente non rientriamo nei requisiti.
L’offensore più grande sono i limiti di visualizzazione delle pagine. 50k/mese di visualizzazioni di pagine è probabilmente più che sufficiente per la maggior parte dei progetti FOSS, ma generiamo molto più traffico di così. Il nostro sito web principale ha ricevuto 1,87 milioni di richieste totali da 56,47k visitatori unici solo negli ultimi 7 giorni. Temo che raggiungeremo facilmente il limite di visualizzazioni di pagine a questo ritmo.
Grazie per avermelo fatto notare!
4 Mi Piace
Probabilmente varrebbe la pena trovare un modo per gestire questo problema. Se sai quali utenti sul tuo server sono staff di Discourse (amministratori o moderatori), forse imposta il campo email SSO per quegli utenti alla loro email effettiva. Qualsiasi account email duplicato che hanno riceverebbe l’indirizzo email fittizio.
Ci sono alcuni casi in cui è utile che lo staff possa ricevere email da Discourse. Il primo che probabilmente incontrerai è che Discourse fornisce un percorso /u/admin-login per gli utenti dello staff. Quel percorso visualizza un modulo che accetta un indirizzo email dello staff. Discourse invierà un link di accesso monouso al membro dello staff. È utile per configurare l’SSO: se ti blocchi accidentalmente dal sito durante la configurazione, ti permetterà di rientrare. È anche utile se ci sono problemi con il tuo server di autenticazione.
1 Mi Piace
Sono d’accordo, ed è qualcosa a cui ho pensato (per ragioni esterne a Discourse). Il grosso problema deriva dal fatto che i membri regolari possono diventare, e sono diventati, staff. Quindi, anche se richiedessimo email uniche per gli utenti staff, non potremmo garantire che gli utenti le abbiano, il che causerebbe problemi quando un utente il cui account ha un’email duplicata diventa un membro dello staff.
Detto questo, ora che è chiaro che DiscourseConnect utilizza prima l’ID univoco per le ricerche utente e la parte “Discourse utilizza le email per associare utenti esterni a utenti Discourse” del post di DiscourseConnect si riferisce solo al collegamento di nuovi utenti SSO a account Discourse esistenti, e il mio fraintendimento di come funziona il prompt di accesso è stato chiarito, c’è qualcosa che ci impedisce effettivamente di inviare semplicemente indirizzi email duplicati così come sono? O questa unicità è rigorosamente applicata?
Sì. Ho omesso un passaggio nella descrizione del flusso di accesso. Discourse tenterà prima di trovare l’utente in base a external_id, quindi tenterà di trovare l’utente in base al suo email. Se nessuno dei due viene trovato, Discourse tenterà di creare l’utente. È così che i tuoi utenti verranno inizialmente registrati su Discourse. Discourse non consente indirizzi email duplicati, quindi se si tenta di creare un utente con un indirizzo email già in uso, Discourse genererà un errore.
Dovrai assicurarti che le email inviate nel payload siano univoche per utente.
Capito, grazie per il chiarimento 
è possibile aggiornare manualmente l’email di un utente in un secondo momento? Ora che il problema del prompt di accesso è stato risolto, potrei prendere in considerazione l’implementazione dell’idea che il mio team aveva prima, utilizzando email false e un server SMTP che gestiamo e che mappa tali email false all’email reale di un utente. Ad esempio, aggiorneremmo l’email di tutti gli utenti di Discourse a qualcosa come userid@example.com, che si collega prima al nostro server SMTP e prende lo userid per cercare l’email reale dell’utente. Tuttavia, non sarebbe qualcosa che avremmo pronto per qualche tempo, quindi avremmo bisogno di aggiornare le email degli utenti di Discourse in seguito, se possibile.
Sì. Sarà necessario abilitare l’impostazione del sito auth overrides email per questo. Quando è abilitata, l’email di un utente di Discourse viene sincronizzata con l’email inclusa nel payload di autenticazione (il payload di DiscourseConnect nel tuo caso) ogni volta che l’utente accede. Se non è abilitata, l’email dell’utente verrà impostata sull’email del payload di autenticazione al momento della creazione iniziale dell’account, ma non verrà aggiornata ai successivi accessi.
Supponendo che auth overrides email sia abilitato, puoi anche aggiornarla senza richiedere agli utenti di accedere effettuando una richiesta API al percorso sync_sso: Sincronizza i dati utente di DiscourseConnect con il percorso sync_sso.
Potresti anche aggiornare gli indirizzi email degli utenti in blocco dalla console Rails del sito, ma (credo) farlo in quel modo attiverà l’invio di un’email di conferma da Discourse all’utente. Ciò non funzionerà con indirizzi email fittizi.
Forse potresti semplicemente impostare le email su qualcosa di significativo all’inizio. Una volta configurato un sito Discourse, dovresti fare alcuni test per vedere quali domini email Discourse accetta per le email fittizie. Ricordo che credo che @invalid.com sia accettato. Non sono sicuro riguardo ad altri domini. Da parte tua, potresti mappare qualcosa come <userId>@invalid.com all’indirizzo email effettivo dell’utente.
Sei stato incredibilmente d’aiuto, grazie mille! La soluzione API è ciò che avevo in mente, ma sapere che può sincronizzarsi da sola funziona perfettamente ugualmente.
Potremmo, sì. Stavo per tentare di usare prima l’indirizzamento plus, in quel modo almeno alcuni utenti riceverebbero ancora email fin dall’inizio. Poi passare al nostro server di mappatura SMTP in seguito per supportare tutti, compresi coloro per cui l’indirizzamento plus non ha funzionato.
1 Mi Piace
@simon @supermathie Siete stati incredibilmente d’aiuto finora, spero di poter uscire leggermente dallo scopo della discussione e chiedervi ulteriore aiuto?
Ho installato Discourse su una macchina locale per il testing, usando Install Discourse for development using Docker come guida. Non sono riuscito a trovare altre guide su come impostarlo per il testing locale? Il wiki sembra coprire solo configurazioni di produzione, che richiedono di avere già impostati dominio/DNS/SMTP. Non volevamo esporre il forum al pubblico finché tutto non fosse stato implementato dalla nostra parte, quindi avevamo bisogno di un testing locale dove nulla di tutto ciò fosse richiesto.
L’ho messo in funzione usando quella guida e ho implementato l’SSO su un’istanza locale del nostro sito, ma finora ho riscontrato 2 problemi:
- Il reindirizzamento a
return_sso_urlsembra funzionare solo a metà? Nel mio caso l’URL èhttp://localhost:3000/session/sso_login. Si reindirizza correttamente, tuttavia dopo il reindirizzamento iniziale mi invia ahttp://localhost:3000, che visualizza semplicemente l’erroreRuntimeError: Discourse non supporta la compilazione di file scss/sass tramite Sprockets. L’unica discussione che ho potuto trovare su questo errore è Error when building: discourse does not support compiling scss/sass files via sprockets, ma non sembrava portare a nulla. L’OP non ha accettato alcuna soluzione, e l’unica cosa che è successa è stata la richiesta di informazioni sulle dimensioni della RAM e dello swap (la macchina su cui è in esecuzione ha 32 GB di RAM e 2 GB di swap. Quindi dubito che questo sia il problema?) avatar_force_updatesembra non essere rispettato? O almeno, non per gli utenti amministratori? Ho abilitatodiscourse connect overrides avatarnelle impostazioni del sito e nel payload della risposta SSO sto impostando siaavatar_urlcheavatar_force_update. Ma quando accedo all’account amministratore (che è collegato al mio account esterno) non viene visualizzata la mia immagine del profilo esterna? Posso vedere cheexternal_avatar_urlviene impostato correttamente quando controllo i dati dell’utente amministratore tramite l’API, semplicemente non sembra essere utilizzato nell’interfaccia utente?
C’è un elenco di metodi di installazione qui: Set up a local Discourse Development Environment?. Ho un sito di sviluppo non-Docker (usando la guida Ubuntu). Se è possibile per te farlo, penso che otterrai i migliori risultati con l’approccio non-Docker. Uno dei motivi per cui lo uso è per non dover affrontare problemi di rete per le richieste API tra Discourse e altre applicazioni che sto sviluppando localmente. È anche più veloce di Docker.
Dovrebbe esserlo. Assicurati che l’applicazione su cui stai generando il payload SSO non stia convertendo il valore booleano true in 1. Questo è un problema comune. Per aggirarlo, puoi impostare qualsiasi valore booleano nel payload SSO sulle stringhe \"true\" o \"false\". Discourse li interpreterà correttamente. Controlla prima questo per vedere se è il problema. Potrebbe essere qualcos’altro. Il codice che gestisce avatar_force_update è piuttosto complesso, ma leggibile: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Modifica: Per il problema dei valori booleani nel payload SSO, immagino sia più accurato dire che nel processo di generazione del payload SSO, l’ambiente convertirà i valori booleani true/false in stringhe. Discourse si aspetta che le stringhe siano \"true\" o \"false\", altri ambienti di programmazione potrebbero gestirli diversamente. Ad esempio:
PHP:
wp> strval(true)
=> string(1) "1"
invece di Ruby:
irb(main):001
=> "true"
Python (non sono sicuro di come Discourse gestisca questo):
>>> str(True)
'True'
2 Mi Piace
Ci proverò. Grazie per avermi indicato quella direzione. È piuttosto controintuitivo, però. Tipicamente la gente cerca la soluzione Docker come metodo “rapido e semplice” per configurare le cose. Questa è la prima volta che mi è stato consigliato di evitare la versione Docker. Anche se rimane la domanda sul perché questo accada con la versione Docker. Usare un altro metodo di installazione per aggirare il problema funziona per ora, ma non risolve il problema sottostante.
Decisamente non è impostato su 1. Sto lavorando in JavaScript e il valore booleano true verrà sempre convertito nella stringa \"true\":
String(true); // 'true'
(true).toString(); // 'true'
// Questo è ciò che il mio codice sta effettivamente usando
querystring.stringify({
avatar_force_update: true
}); // 'avatar_force_update=true'
Non ho mai lavorato con Ruby prima, quindi non so quanto riuscirò a scavare in questo. Ma a prima vista non vedo problemi? Tuttavia, ho verificato che sia l’impostazione pertinente nel pannello di amministrazione di Discourse che nel payload SSO siano impostate:
Non ho testato il tentativo di cambiare l’immagine di un account utente standard da qualcosa di diverso da quello con cui l’account è stato creato, ma quando ho effettuato l’accesso a un account utente standard per la prima volta Discourse ha scaricato l’avatar e lo ha applicato come previsto. L’unico account che non viene aggiornato è l’account amministratore?
A dire il vero, in PHP si vorrebbe quasi sempre usare var_export per ottenere la rappresentazione stringa “reale” di una variabile, poiché restituisce il PHP valido necessario per ricreare tale variabile:
var_export(true); // true
1 Mi Piace
Dai un’occhiata alla sezione DiscourseConnect in fondo alla pagina di amministrazione dell’utente. C’è un pulsante su cui puoi fare clic che si espanderà per mostrare i valori dell’ultimo payload SSO ricevuto da Discourse.
Puoi trovare le stesse informazioni anche dalla console Rails. Ad esempio:
>SingleSignOnRecord.last
# o
>SingleSignOnRecord.where(external_id: 2)
Dovresti abilitare l’impostazione del sito verbose discourse connect logging. Ciò aggiunge alcuni dettagli aggiuntivi ai log generati in Admin / Logs / Error Logs. Per il problema dell’avatar, è possibile che le voci di log pertinenti vengano visualizzate come normali log di errore, non come log di DiscourseConnect.
Forse il problema è specifico di WordPress. Restituisce sempre 1 per true e "1" per la rappresentazione in stringa di true.
1 Mi Piace
È il payload previsto e l’URL dell’immagine del profilo è visualizzato correttamente:
L’immagine del profilo DOVREBBE essere questa:
Tuttavia mostra ancora come:
Che è il mio Gravatar:
A meno che non stia fraintendendo questa impostazione, o a meno che non ci sia qualcos’altro che devo anche impostare, ho abilitato l’impostazione per sovrascriverle:
Ho anche provato in modalità incognito, browser diversi e cancellando la cache del browser per escludere un problema di cache.
Questo è sul tuo sito di sviluppo locale?
Mi chiedo se il caricamento dell’avatar sia fallito per qualche motivo. Prova ad abilitare l’impostazione del sito verbose discourse connect logging, quindi effettua il logout e accedi di nuovo. Dovrebbe esserci almeno un messaggio nei log relativo all’avatar:
Probabilmente ci sarà un altro errore relativo al fallimento del caricamento.
Nel caso non l’avessi ancora capito, questo significa: “devi accedere tramite il proxy ember-cli invece che direttamente da un browser”.
Usa bin/ember-cli -u per avviarlo per lo sviluppo.
Ho duplicato la tua situazione avatar:
prima:
payload di login:
dopo:
ma:
Penso che questo sia un bug in cui Discourse imposta correttamente l’URL dell’avatar personalizzato ma non passa da Gravatar all’immagine personalizzata.
Se creo un nuovo utente:
funziona subito:
quindi sospetto che questo sia attivato dall’avere un account con un gravatar impostato prima di utilizzare DiscourseConnect.
2 Mi Piace
Sono riuscito a far funzionare i passaggi di Ubuntu (dopo un bel po’ di aggiustamenti, poiché lo script di installazione era in conflitto con pacchetti e software che ho già installato). Questo ha risolto l’errore originale che avevo, ma l’SSO funziona ancora solo a metà. Ora, invece dell’errore scss/sass, l’SSO restituisce ogni volta Account login timed out, please try logging in again. Cliccare sul pulsante Login una seconda volta mentre ci si trova in questa pagina di errore completa il login, tuttavia. Non ci sono state modifiche al codice da parte mia, solo il modo in cui Discourse è in esecuzione.
Considererò tutto questo come delle stranezze dell’esecuzione locale. Spero che un’installazione in produzione non presenti gli stessi problemi.
Questo non sembra aver fatto nulla con la versione Docker. Lo script usciva senza output e nulla sembrava realmente accadere dal lato Discourse. Ciò va anche contro i passaggi elencati nella guida Docker, il che sembra strano. C’è un motivo per cui non viene menzionato lì?
Mi sembra strano che il metodo Docker sembri avere questi problemi e che il consiglio ufficiale sia di installare Discourse nativamente (nonostante lo script di installazione non funzioni sempre subito, poiché presuppone cose come l’uso di bashrc e tenterà di installare versioni di pacchetti potenzialmente conflittuali già installati)? Ci dovrebbe forse essere un avviso sui potenziali problemi con tutte le versioni di hosting disponibili? Già a prima vista non è chiaro quale sia quella da scegliere, e tipicamente le persone presumono che se è disponibile una build Docker, quella dovrebbe essere la scelta principale.
Sono contento di sapere che non sono l’unico! 
I bug non sono mai divertenti, ma sono felice di aver contribuito a trovarne uno.
Potrebbe essere così, ma dovresti essere in grado di far funzionare DiscourseConnect in locale senza problemi. Stai accedendo a Discourse da http://localhost:4200? C’è un problema strano (secondo me) per cui Discourse può essere accessibile sia da localhost:4200 che da 127.0.0.1:4200 in un ambiente di sviluppo locale. Ti consiglio di usare il dominio localhost. Viene trattato come una sessione diversa da 127.0.0.1.
Comunque, questa è solo un’ipotesi su cosa sta succedendo. Assicurati di abilitare l’impostazione di logging dettagliato e controlla i log per i dettagli.
Le istruzioni di installazione dovrebbero chiarire che non è necessario eseguire lo script. Puoi semplicemente seguire lo script passo dopo passo per assicurarti che tutte le dipendenze siano installate.
Sì.
Quelle linkate in precedenza non lo chiariscono. Sono andato su Set up a local Discourse Development Environment? e ho selezionato Install Discourse on Ubuntu or Debian for Development poiché sto usando Ubuntu 22.04.3. Questa pagina dice che non devi eseguire l’intero script, ma solo in piccolo testo dopo la parte che istruisce gli utenti a eseguirlo.
Per me questo non era chiaro, poiché leggendo le istruzioni dall’alto verso il basso si presume naturalmente che si debba finire il passaggio corrente prima di continuare. Quindi ho combattuto con lo script di installazione, installando solo ciò di cui avevo bisogno, solo per poi continuare a leggere dopo aver finito per vedere che era stato previsto per tutto il tempo e che non avevo dovuto combattere con nulla.
Mettere quel disclaimer dopo le istruzioni non le rende affatto chiare, secondo me.
1 Mi Piace
Sembra che ritenga che il nonce non sia corretto? Sto vedendo questo nei log ora durante l’accesso:
Impossibile verificare l'autenticità del token CSRF. 15:44
Log SSO dettagliato: Avviato processo SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 15:44
Log SSO dettagliato: Nonce non corretto, è stato generato in una sessione del browser diversa o è scaduto add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 15:44
Log SSO dettagliato: Avviato processo SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 15:44
Log SSO dettagliato: L'utente è stato registrato su PN_Jon add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 15:44
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb) non trovato: Nessun file o directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 15:44
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb) non trovato: Nessun file o directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 15:44
Dopo un’ulteriore ispezione, sembra che sia perché il reindirizzamento SSO non sta utilizzando localhost. Mi sta reindirizzando a 127.0.0.1. Se passo dall’uso di localhost all’uso di 127.0.0.1 inizialmente, il problema viene risolto.