Pregunta rápida, ¿hay alguna forma de usar Discourse internamente, solo en mi red, no a través de Internet?
Digamos que mi dominio en casa se llama testlabs.local, quiero que todos los usuarios de este dominio puedan acceder a Discourse. Puedo acceder a él a través del puerto 80, pero cuando registro mi cuenta, establezco un nombre de usuario y una contraseña, y luego, cuando continúo, me aparece un mensaje de nginx 404, la página está en blanco. Curiosamente, aunque da error, todavía recibo el correo electrónico, pero cuando hago clic en el enlace, vuelvo a obtener un error 404.
¿Se puede usar internamente como quiero?
¿O solo se puede usar externamente?
Si es así, ¿hay alguna guía para configurarlo internamente porque todo lo que veo es la guía en la nube?
En el archivo yaml configuré mi configuración smtp, puedo recibirla. No tengo claro el campo de nombre de usuario y contraseña smtp. Simplemente los comento, ¿es necesario configurarlos? Si es así, ¿por qué sigo recibiendo correos electrónicos sin esa configuración?
Simplemente no quiero poner una contraseña de correo electrónico allí en texto plano.
Cualquiera de estas opciones te permitirá usar Discourse a través de http://localhost:4200/ Todas estas opciones usan MailHog para probar SMTP sin enviar correos electrónicos reales.
Actualización: Volví a leer la pregunta y veo que quieres permitir que otras personas lo usen. No sé si esta respuesta realmente ayuda.
Discourse en su mayor parte no funcionará sin https, lo cual es difícil de configurar en una red local. Podrías unirte consultar guías que involucren un proxy inverso como guía, pero no es una configuración compatible.
Gracias por tu respuesta, sí, quiero que otras personas también lo usen. Solo quiero aclarar que estas otras personas forman parte de mi red local, todo se accederá en casa, sin acceso público.
¿Funcionaría habilitar solo invitación y requerir inicio de sesión para poner Discourse en Internet, pero restringir quién puede verlo? ¿O tal vez usar debe aprobar usuarios (quizás con dominios de correo electrónico de aprobación automática) para permitir solo a los usuarios de su organización unirse?
Supongo que la pregunta es ¿qué problema estás resolviendo?
Gracias por tu respuesta. Actualmente lo tengo configurado en una distribución Red Hat internamente en mi dominio, solo para uso interno. Intentaré jugar con él. ¿Qué quieres decir exactamente cuando dices que no funcionará sin https? ¿Entonces está diseñado solo para funcionar externamente, para ser accedido solo a través de Internet público?
¿Puedes por favor dar más detalles sobre la guía del proxy inverso? No entiendo a qué te refieres con “join at guides”.
Actualmente solo estamos probando el producto, queremos usarlo como un foro interno para nuestra empresa.
Para que los desarrolladores y TI publiquen y puedan interactuar entre sí. Queremos que sea solo interno, sin acceso público.
Esta es la solución en la que están decididos. No puedo controlar eso.
Creo que la configuración de debe aprobar usuarios cumple eficazmente con ese requisito. Muchas herramientas “internas” (Slack, Google Suite, Microsoft Office 360, GitHub Enterprise, etc.) se alojan en Internet, pero se restringen solo a los usuarios que el administrador del cliente aprueba.
Si ponerlo en una red interna es un requisito de TI, también deberían poder ayudar a configurar la red para Discourse.
Entiendo, pregunto cuál es el proceso para que funcione solo para acceso interno. No hay una guía de configuración y los usuarios dicen que no funciona bien sin https.
En realidad, acabo de configurar una red local en mi laboratorio y la probaré, pero por pruebas anteriores no funcionó internamente. Lo intentaré de nuevo.
Me refiero a que gran parte del código del front-end asume que estás usando https. Me refiero a que la instalación estándar asume que tu sitio puede obtener un certificado de let’s encrypt.
Aquí tienes una. Para que esto funcione, necesitarás configurar Apache con un certificado válido y luego hacer que actúe como proxy inverso para Discourse.
No es una configuración compatible. Si estar detrás de un firewall/NAT es un requisito, entonces tener a alguien que sepa cómo configurar un proxy inverso interno con un certificado válido y pueda seguir una de las guías como la que se ha enlazado es el coste de ese requisito.
Tienen personal de TI allí. Pueden crear certificados porque de todos modos usan servidores web en su intranet. El único problema es obtener un certificado que sea aprobado por los navegadores.
