Pergunta rápida, existe uma maneira de usar o Discourse internamente, apenas em minha rede, não pela internet?
Digamos que meu domínio em casa se chame testlabs.local, quero que todos os usuários deste domínio possam acessar o Discourse. Posso acessá-lo pela porta 80, mas quando registro minha conta, defino um nome de usuário e senha e, em seguida, quando continuo, recebo uma mensagem 404 do nginx, a página está em branco. Estranhamente, mesmo que ocorra um erro, ainda recebo o e-mail, mas quando clico no link, recebo um erro 404 novamente.
Então, isso pode ser usado internamente como eu quero?
Ou isso só pode ser usado externamente?
Se sim, existem guias para configurar isso internamente, porque tudo o que vejo é o guia da nuvem.
No arquivo yaml, configurei minhas configurações de smtp, posso recebê-las. Não tenho clareza sobre os campos de nome de usuário e senha do smtp. Apenas comento essas linhas, isso precisa ser configurado? Se sim, por que ainda recebo e-mails sem essa configuração?
Eu só não quero colocar uma senha de e-mail lá em texto simples.
Qualquer um destes permitirá que você use o Discourse via http://localhost:4200/ Todas essas opções usam o MailHog para testar SMTP sem realmente enviar e-mails.
Atualização: Re-li a pergunta e vi que você quer permitir que outras pessoas o usem. Não sei se esta resposta realmente ajuda.
O Discourse, em sua maioria, não funcionará sem https, o que é difícil de configurar em uma rede local. Você pode entrar olhar guias que envolvem um proxy reverso como um guia, mas não é uma configuração suportada.
Obrigado pela sua resposta, sim, eu quero que outras pessoas o usem também. Apenas quero esclarecer que essas outras pessoas fazem parte da minha rede local, todas serão acessadas em casa, sem acesso público a ele.
Funcionaria habilitar somente convite e login obrigatório para colocar o Discourse na internet, mas restringir quem pode vê-lo? Ou talvez usar aprovar usuários (talvez com domínios de e-mail de aprovação automática) para permitir apenas que usuários da sua organização participem?
Acho que a pergunta é qual problema você está resolvendo?
Obrigado pela sua resposta. Atualmente, configurei em uma distribuição Red Hat internamente em meu domínio, apenas para uso interno. Tentarei brincar com isso. O que exatamente você quer dizer quando diz que não funcionará sem https? Então, ele foi projetado apenas para funcionar externamente, para ser acessado apenas pela internet pública?
Você pode, por favor, elaborar mais sobre o guia de proxy reverso? Eu não entendo o que você quer dizer com “join at guides” (juntar-se aos guias).
Atualmente estamos apenas testando o produto, queremos usá-lo como um fórum interno para nossa empresa.
Para que desenvolvedores e TI postem e possam interagir uns com os outros. Queremos que seja apenas interno, sem acesso público.
Esta é a solução em que eles estão definidos. Eu não posso controlar isso
Penso que a configuração must approve users atende efetivamente a esse requisito. Muitas ferramentas “internas” (Slack, Google Suite, Microsoft Office 360, GitHub Enterprise, etc.) são hospedadas na internet, mas restritas apenas aos usuários que o administrador do cliente aprova.
Se colocar em uma rede interna é um requisito de TI, eles também devem ser capazes de ajudar a configurar a rede para o Discourse.
Entendo, estou perguntando qual é o processo para que funcione apenas para acesso interno? Não há um guia de configuração para isso, e os usuários estão dizendo que não funciona bem sem https.
Na verdade, acabei de configurar uma rede local no meu laboratório e vou testar, mas de testes anteriores não funcionou internamente. Tentarei novamente.
Quero dizer que um monte de código front-end assume que você está usando https. Quero dizer que a instalação padrão assume que seu site pode obter um certificado do let’s encrypt.
Aqui está um. Para que isso funcione, você precisará configurar o apache com um certificado válido e, em seguida, fazer com que ele faça proxy reverso do Discourse.
Não é uma configuração suportada. Se estar atrás de um firewall/NAT é um requisito, então ter alguém que saiba como configurar um proxy reverso interno com um certificado válido e possa seguir um dos guias como o vinculado acima é o custo desse requisito.
Essa é uma maneira mais educada de dizer o que eu disse.
Vocês têm pessoal de TI lá. Eles podem criar certificados porque já usam servidores web na sua intranet. A única questão é obter um certificado que seja aprovado pelos navegadores.
