Al momento non ho un’installazione locale di Discourse, quindi non sono sicuro di quanto io possa aiutare.
La risposta 404 mi fa chiedere se Discourse Connect sia effettivamente abilitato sul tuo sito Discourse:
Sembra che tu stia testando questo con un’app Angular locale e un sito Discourse di produzione. Mi aspetterei che funzioni ancora, ma forse sta causando un problema. Dovresti assolutamente essere in grado di ottenere una risposta diversa da una 404.
@simon grazie per la tua risposta,
questo era stato confermato più volte da me,
e ho anche un sito di test di produzione che era ospitato sul dominio principale di questo sito Discourse. se puoi dare un’occhiata a questo [link rimosso]
per testare il flusso di produzione ho aggiornato l’URL di Discourse Connect a “https://domainsite.com/login” sentiti libero di accedere con il provider Google e fare un test. Nel log della console di ispezione vedrai l’errore e la risposta che ho stampato, che è 404
dato che sto solo facendo il POC se non ti dispiace puoi lasciarmi la tua email così posso impostarti come amministratore per indagare da vicino sulle configurazioni sul mio sito Discourse. Ancora una volta, apprezzo davvero il tuo tempo e il tuo aiuto
l’unica parte di cui non sono sicuro è il sig e il sso sto facendo correttamente dal codice?
oltre questa parte. l’api-key ho provato entrambe, generando per tutti e solo per il sistema, i risultati sono gli stessi. se possibile, per favore forniscimi un esempio funzionante per Postman o codice basato su Angular
Mi è sfuggito questo particolare quando ho guardato per la prima volta lo screenshot del tuo codice:
mode: 'no-cors'
Non ho familiarità con le app Angular, ma sembra che tu stia cercando di effettuare una richiesta API autenticata a Discourse dal client. Non sono sicuro di dove avvenga nel codice di Discourse, ma la mia comprensione è che Discourse blocchi le richieste API di amministrazione effettuate dal client. Questo perché non c’è modo di effettuare la richiesta senza esporre la chiave API sul client. In relazione a ciò, dovresti cambiare la tua chiave API ora.
grazie per averlo segnalato,
sembra di fare un passo avanti.
Sto anche cercando di inviare la richiesta da Postman.
se pensi che il blocco dal lato client “mode: ‘no-cors’” poiché discourse ha rifiutato di accettare la chiamata con le chiavi API dal frontend, allora penso che dovrebbe andare bene inviarla da Postman è corretto? ma il risultato è lo stesso
Ho persino provato ad avviare un server, quindi a innescare il server per inviare la richiesta con la chiave API sul lato server, il che dà lo stesso risultato, facendomi sentire che mi mancano alcune configurazioni sul sito discourse.
È una buona idea far funzionare questo da Postman, o anche solo dalla riga di comando. Dallo screenshot che hai pubblicato, sembra che tu abbia api-username e api-key nel corpo della richiesta. Quei parametri devono essere nell’intestazione della richiesta. Il corpo della richiesta dovrebbe contenere le coppie chiave/valore sig e sso. Se può essere d’aiuto, ecco come lo gestisce il plugin WP Discourse: wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub .
wow! ci siamo,
ora funziona!
1000 grazie @simon
il problema era proprio quello che hai menzionato:
sso e sig dovrebbero essere le uniche due coppie di chiavi nel corpo
api-key e api-username dovrebbero essere nelle intestazioni
Come si comporterà se lo attivo su un sito che non utilizza attualmente external_id? Riuscirà ad accedere agli utenti basandosi esclusivamente sulla loro email?
Più in generale, poiché email e external_id sono i 2 campi obbligatori nel payload, potresti chiarire come vengono utilizzati sul lato discourse (quando si riceve il payload dal sito di autenticazione) per capire quale account utente accedere?
external_id è stato associato all’email durante la creazione dell’utente, utilizzerà l’email e quindi assocerà l’external_id a questa email per accessi futuri?email e external_id (ciascuno associato a un account discourse diverso), utilizzerà external_id o email per capire quale utente accedere? O genererà un errore?Grazie!
Penso che la tua domanda principale riguardi il campo external_id. Devi impostare un campo external_id nel payload di DiscourseConnect. Il valore del campo dovrebbe essere una stringa associata all’utente che non cambierà mai. Presumo che la tua applicazione abbia una tabella users. La chiave primaria per la voce di un utente in quella tabella sarebbe un buon valore da usare per il campo external_id.
Se un utente ha creato un account su Discourse prima che tu aggiungessi l’autenticazione DiscourseConnect dal tuo sito web, la prima volta che accede a Discourse tramite DiscourseConnect, Discourse tenterà di trovare l’utente in base all’indirizzo email presente nel payload di DiscourseConnect. Dopo aver trovato l’utente, verrà aggiunto un record al database di Discourse contenente l’external_id dal payload di DiscourseConnect. La prossima volta che l’utente accede, verrà trovato tramite l’external_id invece che tramite l’indirizzo email. (Nota che questo non funziona se imposti il parametro require_activation nel payload di DiscourseConnect su true.)
Discourse ha buoni fallback per la maggior parte dei casi limite. Ci sono problemi relativi agli utenti che hanno più account e indirizzi email che possono causare errori. Alcuni dettagli su come gestire questi casi sono qui: Debug e risoluzione dei problemi comuni di DiscourseConnect.
Molto utile, grazie! Sembra che funzioni tutto come mi aspettavo 
Utilizziamo DiscourseConnect con WordPress come provider con successo da diversi anni e non abbiamo modificato le configurazioni di Discourse o WP. Oggi noto quello che penso sia un nuovo comportamento.
Quando effettuo il logout, mi portava alla schermata di login di WordPress. Ora mi porta alla schermata di login di Discourse. Se provo ad accedere con la schermata di Discourse, ricevo un Errore sconosciuto, ma il punto è che non dovrei essere lì affatto, dovrei essere al login di WP.
Nota: ho abilitato i login locali (non so perché, dato che uso WP). Se disabilito i login locali e provo ad accedere, dice che non ci sono metodi di accesso disponibili. Quindi, immagino che non gli piaccia la mia connessione WP, ma ancora una volta, non ho modificato le configurazioni su nessuna delle due estremità. Ho confermato che Discourse Connect è abilitato, l’URL di connessione è corretto e il segreto è lo stesso su entrambe le estremità.
Aggiornato a 3.5.0.beta5-dev. Anche il plugin WP Discourse è aggiornato.
sta succedendo anche a me, ci giocherò per vedere se riesco a trovare il problema.
Anche noi stiamo utilizzando DiscourseConnect e riscontriamo lo stesso problema.
Lo abbiamo messo in funzione da alcuni anni e tutto ha funzionato senza intoppi. Aggiornato oggi a 3.5.0.beta8-dev [e91024a221]
Fondamentalmente, il callback dal sistema sso all’URL di discourse aggiunge https://discourse.domain.ext/login e abbiamo la stessa schermata di @markschmucker
Abbiamo anche notato che cliccando sul logo nell’intestazione si arriva a https://discourse.domain.ext/ e l’accesso viene effettuato con successo (basta un clic su un pulsante).
Sembra che nella versione precedente il session controller si comportasse diversamente, probabilmente capendo che la chiamata era stata avviata da un sso esterno e gestendola nel modo corretto.
Ho notato che nell’ultimo mese @zogstrip ha apportato alcune modifiche che potrebbero essere correlate (non sono sicuro al 100%) al malfunzionamento.
Per ora abbiamo applicato una soluzione temporanea nel metodo di callback che aggiungeva /login all’URL di discourse e tutto sembra funzionare correttamente.
Se mi manca qualcosa, come documentazione che forniva consigli su un cambiamento potenzialmente dirompente in questa porzione di codice, fatemelo sapere.
Grazie a tutti per il vostro supporto.
@markschmucker, @jimkleiber e @marco.palumbo avete lo stesso problema evidenziato in No login methods when using Discourse Connect only?
Se sì, la soluzione è assicurarsi di aver abilitato l’impostazione del sito “auth immediately”.
Ho abilitato “autenticazione immediata”.
Grazie per il tuo aiuto su questo @zogstrip. Sfortunatamente, se abilito “auth immediately”, perdo la capacità di avere una pagina di “benvenuto” per gli utenti anonimi.
Sembra che non sia possibile rimuovere un nome o un avatar_url usando DiscourseConnect SSO. Ho provato a impostare i campi su una stringa vuota (confermato ad esempio che avatar_url= finisce nel parametro SSO base64), ma immagino che il codice ignori i campi vuoti.
Nomi e immagini sono opzionali sul mio sistema, ma nel modo in cui funziona ora, una volta impostati, non possono mai essere rimossi, solo sostituiti. C’è qualche possibilità che stia facendo qualcosa di sbagliato? (Se no, forse questo potrebbe essere corretto?)
[Modifica]: Avevo già cercato una risposta, ma ovviamente appena ho pubblicato quanto sopra, ho provato a cercare parole chiave diverse e ho trovato Allow name removal using SSO - #9 by mentalstring. Ho votato a favore ma non mi faccio illusioni. 
Ho lo stesso problema di reindirizzamento del login che @markschmucker, @jimkleiber e @marco.palumbo descrivono sopra, che ho scoperto qualche settimana fa e sapevo che aveva funzionato correttamente a maggio. Leggendo quello che avete detto al riguardo sopra, sono convinto che si tratti di una regressione in Discourse introdotta in qualche aggiornamento di maggio, perché ha colpito tutti noi contemporaneamente, avevamo tutti codice SSO funzionante e non condividiamo alcun codice SSO in comune.
Ho pubblicato un report di bug nella speranza di risolvere il problema.
Il problema del reindirizzamento è stato risolto per me in 3.6.0-beta1.
@markschmucker e @marco.palumbo
Sembra che questo sia stato risolto un paio di settimane fa e dovrebbe funzionare di nuovo correttamente in v3.6.0.beta1.