Multiple sites with the same user accounts?

Hi… I’ve searched / browsed this forum but couldn’t find a simple explanation. Is multisite a feature where you want multiple separate sites but on the same server?

What I’m really looking for / wondering is if you can set up multiple forums on the same server, that share the same user database? Sorry if this has already been asked.

To share the userbase, simply have one of the forums be the sso provider and have the other forums be an sso consumer.

5 Mi Piace

Note that this is visible to the user: When they want to log in, they always go to the same site. This could be confusing, depending on the use case. If you want to avoid that, you need to set up an external SSO provider.

Also note that this will share the credentials, but not the user profiles, group memberships, …

Profile stuff can be handled in the payload.

Related:

https://meta.discourse.org/t/can-multisite-instances-communicate-with-one-another/8984?u=erlend_sh

1 Mi Piace

Are there any newer/better approaches to this since the last post? This is something we want to do as well.

We definitely want to share user profiles so that badges (for example) only have to be earned once overall, not once per site.

Using discourse in multiple sites with shared accounts? suggests that just SSO will do the trick but Multiple sites with the same user accounts? suggests that using SSO just takes care of the authentication (credentials) but nothing else.

If you want shared badges, like using the sum for each site to get a badge, you gotta use a single forum and categories to separate stuff.

5 Mi Piace

Quindi, qual è il modo migliore per gestire questa situazione? Si configura un sito centrale principale e si incorporano i link di Discourse su altri siti (in modo che i loro post di conversazione siano essenzialmente archiviati/“su” un sito centrale)?

“Migliore” è relativo se non si dichiarano le proprie capacità.

La soluzione più semplice è esattamente ciò che è stato detto nel post sopra il tuo: utilizzare un’unica istanza.

Se si dispone delle capacità ingegneristiche, o dell’equivalente in termini di budget, è possibile avere più istanze che condividono un singolo SSO e un’applicazione complementare che interroga tutte le istanze Discourse sorelle per i dati e assegna un badge agli utenti su ciascuna istanza tramite chiamate API.

3 Mi Piace

Quindi, essenzialmente, un plugin per la sincronizzazione dei profili SSO. Sai se esiste qualcosa del genere? Qualcuno sta già lavorando a qualcosa di simile? Anch’io sono interessato.

Ho letto che i login alternativi, come Facebook, vengono persi quando si utilizza l’SSO. È ancora così oggi? Anche il Discourse centrale non avrebbe quei login alternativi? Perché è così?

Potresti configurare un Discourse come sito principale e altri impostati per avere il sito principale come server SSO. In tal caso, il Discourse principale potrebbe utilizzare l’accesso tramite social, mentre quelli che lo utilizzano come server SSO reindirizzerebbero tutti i loro accessi al server principale.

Se utilizzi SSO, questo è l’unico metodo di autenticazione disponibile. Se desideri delegare in modo ottimale a un altro server, devi utilizzare OAuth2.

1 Mi Piace

Cosa succede quando un utente di un Discourse ‘slave’ tenta di accedere? Vengono reindirizzati alla creazione dell’account sul Discourse ‘master’, che include qualsiasi login tramite social media che desideri, e poi reindirizzati indietro al Discourse ‘slave’ e chiesti di accedere con quali credenziali se hanno utilizzato un login tramite social media come Facebook dopo il completamento della creazione dell’account? Scusa la domanda lunga… fondamentalmente, una rete Discourse che si affida al Discourse ‘master’ e che permette i login tramite social media: i Discourse ‘slave’ utilizzano quindi l’autenticazione locale archiviata sul Discourse ‘master’ o utilizzano ancora, ad esempio, l’autenticazione tramite Facebook? Sembra che potrebbe creare confusione per i gestori di password locali.

tldr; voglio che il mio master e gli slave permettano i login tramite social media

Il client reindirizza al discorso principale. Gestisce l’autenticazione. È lì che gli utenti accedono. Può utilizzare i social.

I siti di discorso del client non sanno se l’utente ha utilizzato i social quando ha effettuato l’accesso (almeno non credo).

2 Mi Piace

Quindi, quando un ospite accede su slave, viene reindirizzato a master dove effettua l’accesso tramite social, per poi essere reindirizzato nuovamente su slave già loggato?

1 Mi Piace