Visualizzo questo messaggio quando tento di attivare Discourse_id sul mio sistema di test (3.6.0.beta2-latest):
enable_discourse_id: Devi configurare le credenziali di Discourse ID ('discourse_id_client_id' e 'discourse_id_client_secret') prima di abilitare questa impostazione.
Utilizzo un server Oauth locale per OIDC qui (keycloak). Forse i due metodi si stanno interferendo a vicenda??
Non credo interferisca con OIDC, ma se la tua istanza non è disponibile su Internet, la registrazione dell’ID non funzionerà. Il provider di identità Discourse ID ha un meccanismo di verifica in atto per le istanze Discourse che avviano il processo di registrazione.
L’istanza di test è online su forum2.netzwissen.de
Vedo lo stesso messaggio su 2 istanze, nessuna delle quali ha una connessione OAuth diversa.
Ho spostato questo in un argomento separato… vedi errori in /logs sulla tua istanza? Dovrebbe fornire maggiori dettagli su ciò che non funziona sotto il cofano durante il processo di registrazione.
Vorrei capirlo un po’ di più dal punto di vista tecnico.
Sulle mie istanze, utilizzo l’autenticazione OIDC con un provider di identità esterno (Keycloak 26). Discourse ID sembra molto simile; è solo un server IDP diverso ospitato da Discourse.org. E anche i messaggi di errore (client ID e segreto mancanti) ricordano il classico flusso OAuth. Ciò significa che Discourse ID verrà attivato come percorso di autenticazione IDP aggiuntivo? Perché solo allora sarebbe utile per il mio caso d’uso. ???
solo questo, ma relativamente regolarmente in modo che non abbia nulla a che fare con l’argomento.
Messaggio (2 copie segnalate)
Sidekiq sta consumando troppa memoria (utilizzando: 503,02M) per 'rpg-foren-app', riavvio
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload
'
Sì, corretto, Discourse ID è un altro IDP.
@Tealk l’errore di sidekiq non è correlato. Puoi condividere l’hash del commit per la tua istanza per favore?
Certo, ecco: 3.5.1 (c96aeda334)
Ok. Avrei quindi bisogno di un ID client sul tuo IDP (per il flusso di accesso pubblico) o di un ID client e di un segreto client (per il flusso di accesso confidenziale). Un’altra opzione: aggiungere Discourse ID come broker di identità esterno all’IDP locale. Per entrambe le varianti sarebbero necessarie maggiori informazioni 
…
Sì, ogni istanza di Discourse si registra (sotto il cofano) e imposta un ID client e un segreto.
Ora che guardo la tua istanza, vedo errori http/https. Affinché l’ID funzioni, il sito deve essere sotto https. Questo è probabilmente il tuo problema.
@Tealk assicurati che anche il tuo sito funzioni correttamente su https.
Non saprei cosa potrei migliorare:
Discourse ID funziona già sui forum che utilizzano la branch stabile? Pensavo che la funzionalità sarebbe stata aggiunta solo dopo il rilascio di agosto.
Ah, in effetti, se ti trovi sul canale stable @Tealk, dovrai attendere la prossima release stabile affinché Discourse ID sia disponibile per te.
Nota anche che DiscourseConnect è una funzionalità separata.
Va bene, allora è confuso nella pagina delle novità. Sarebbe possibile aggiungere da quale versione è inclusa una funzionalità?
Questo è un buon punto. Ho aggiornato il feed Novità per includere questo elemento solo per le istanze che non sono in versione stabile (e che hanno il commit in latest che sblocca l’ID di Discourse). Se aggiorni il feed Novità, non dovresti più vedere questo elemento nella tua istanza in versione stabile.
Ho già le impostazioni nelle Impostazioni, l’impostazione dovrebbe essere disponibile prima che venga implementata?
L’impostazione del sito enable_discourse_id non dovrebbe essere presente per te. (Assicurati di non confonderla con enable_discourse_connect, quella è un’altra cosa.)
Ora che guardo la tua istanza, vedo errori http/https. Affinché l’ID funzioni, il sito deve essere sotto https. Questo è probabilmente il tuo problema.
… interessante, ma non capisco perché. Forse abbiamo una lacuna concettuale qui: i container di Discourse si trovano dietro un acceleratore SSL, accessibile solo tramite https. Ma questo vale per la connessione standard che proviene dall’“esterno” verso l’“interno”. Nel caso d’uso OAuth, il container di Discourse avvia la connessione dall’“interno” verso l’IDP che si trova all’“esterno”. Non vedo alcuna opzione per configurare questa connessione all’ID di Discourse e forzarla a essere “https”.
Se confronto questo con le impostazioni OIDC classiche utilizzate per la configurazione OAuth con il mio IDP: lì abbiamo un’impostazione “Documento di discovery OpenID Connect”
https://....realms/[realm-name]/.well-known/openid-configuration
Penso che abbiamo bisogno di qualcosa di simile per l’ID di Discourse per evitare problemi con connessioni https mancanti. PS. La mia istanza di test ha 3.6.0.beta2-latest, Commits · discourse/discourse · GitHub
