Domanda veloce, c’è un modo per usare discourse internamente, solo sulla mia rete, non su internet?
Diciamo che il mio dominio a casa si chiama testlabs.local, voglio che tutti gli utenti di questo dominio possano accedere a discourse. Posso accedervi tramite la porta 80 ma quando registro il mio account imposto un nome utente e una password e poi quando continuo mi compare un messaggio nginx 404, la pagina è vuota. Stranamente, anche se dà errore, ricevo comunque l’email ma quando clicco sul link ottengo di nuovo un errore 404.
Quindi può essere usato internamente come voglio?
O deve essere usato solo esternamente?
Se sì, ci sono guide per configurarlo internamente perché vedo solo la guida cloud.
Nel file yaml ho impostato le mie impostazioni smtp, posso riceverle. Non mi sono chiari i campi nome utente e password smtp. Li ho solo commentati, devono essere configurati? Se sì, perché ricevo comunque email senza quella configurazione?
Ognuno di questi ti permetterà di usare Discourse tramite http://localhost:4200/ Queste opzioni usano tutte MailHog per testare SMTP senza inviare effettivamente email.
Aggiornamento: Ho riletto la domanda e vedo che vuoi permettere ad altre persone di usarlo. Non so se questa risposta aiuti davvero.
Discourse non funzionerà quasi mai senza https, che è difficile da configurare in una rete locale. Potresti unirti consultare guide che includono un proxy inverso come guida, ma non è una configurazione supportata.
Grazie per la tua risposta, sì, voglio che anche altre persone lo usino. Voglio solo chiarire che queste altre persone fanno parte della mia rete locale, saranno tutte accessibili in casa, nessun accesso pubblico ad essa.
Funzionerebbe abilitare solo su invito e accesso richiesto per mettere Discourse su Internet, ma limitare chi può vederlo? O forse usare gli utenti devono essere approvati (magari con domini email approvati automaticamente) per consentire solo agli utenti della tua organizzazione di unirsi?
Immagino che la domanda sia quale problema stai risolvendo?
Grazie per la tua risposta. Attualmente l’ho configurato su una distribuzione Red Hat internamente nel mio dominio, solo per uso interno. Proverò a sperimentare. Cosa intendi esattamente quando dici che non funzionerà senza https? quindi è progettato per funzionare solo esternamente, per essere accessibile solo tramite Internet pubblico?
Puoi per favore elaborare di più sulla guida del proxy inverso? Non capisco cosa intendi con “join at guides”.
Attualmente stiamo solo testando il prodotto, vogliamo usarlo come forum interno per la nostra azienda.
Per sviluppatori e IT per pubblicare e poter interagire tra loro. Vogliamo che sia solo interno, nessun accesso pubblico.
Questa è la soluzione su cui sono decisi. Non posso controllarlo.
Penso che l’impostazione must approve users soddisfi efficacemente quel requisito. Molti strumenti “interni” (Slack, Google Suite, Microsoft Office 360, GitHub Enterprise, ecc.) sono ospitati su Internet, ma sono limitati solo agli utenti approvati dall’amministratore del cliente.
Se metterlo su una rete interna è un requisito IT, dovrebbero anche essere in grado di aiutare a configurare il networking per Discourse.
Capisco, sto chiedendo qual è il processo affinché funzioni solo per l’accesso interno? Non esiste una guida all’installazione e gli utenti affermano che non funziona bene senza https.
In realtà ho appena configurato una rete locale nel mio laboratorio e la testerò, ma dai test precedenti non ha funzionato internamente. Ci riproverò.
Intendo dire che gran parte del codice front-end presuppone che tu stia usando https. Intendo dire che l’installazione standard presuppone che il tuo sito possa ottenere un certificato da let’s encrypt.
Eccone una. Affinché funzioni, dovrai configurare Apache con un certificato valido e poi farlo agire come proxy inverso per Discourse.
Non è una configurazione supportata. Se trovarsi dietro un firewall/NAT è un requisito, allora avere qualcuno che sappia come configurare un proxy inverso interno con un certificato valido e che possa seguire una delle guide come quella linkata sopra è il costo di tale requisito.
Questo è un modo più gentile di dire quello che ho detto.
Avete lì dei tecnici IT. Possono creare un certificato perché tanto utilizzano webserver sulla vostra intranet. L’unico problema è ottenere un certificato approvato dai browser.
