Hola.
Tenemos una instalación de Discourse v2.4.0.beta2 +346 que estaba originalmente disponible en include.metaring.com,
utilizando Apache HTTP Server en Ubuntu que:
- Redirige todas las solicitudes HTTP a HTTPS
- Gestiona por sí mismo el certificado SSL (LetsEncrypt)
- Todas las solicitudes eran redirigidas por Proxy para usar nginx http sock, por lo que los puertos Docker de Discourse 80 y 443 están desactivados/no utilizados
Hicimos:
./launcher enter app
rails c
[1] pry(main)> SiteSetting.force_https = true
=> true
Para estar extremadamente seguros de que todo se servía en HTTPS (teníamos varios errores si no era así)
Y todo funcionaba correctamente.
Luego decidimos mover la aplicación (sin tocar la base de datos ni otra cosa) a include.metaring.com/discourse, así que editamos el archivo app.yml de la siguiente manera:
DISCOURSE_HOSTNAME: include.metaring.com<— Sin cambios, igual que antesDISCOURSE_RELATIVE_URL_ROOT: /discourse
Luego, para estar extremadamente seguros, hicimos:
./launcher stop app
./launcher destroy app
./launcher cleanup
./launcher rebuild app
Por supuesto, también insertamos en el archivo de configuración de Apache las reglas para ProxyPass correctamente desde /discourse hacia unix:/../../nginx.http.sock|http://localhost/*discourse*
Después de esto, la aplicación estaba, por supuesto, en línea, pero tenía muchos problemas:
-
Todo el contenido estático (plugins, activos, imágenes, scripts de JavaScript, subidas) no estaba disponible. Después de largas sesiones de depuración y búsquedas en la web infructuosas para hacerlos funcionar, creamos algunas reglas de proxy en Apache para tunelizarlos hacia la ruta localhost de raíz, sin el prefijo /discourse (por ejemplo, /disourse/plugins apunta a → unix:/../../nginx.http.sock|http://localhost/plugins y así sucesivamente)
-
Algunas rutas /uploads provenían de páginas web sin el prefijo /discourse, por lo que tuvimos que escribir otra regla de proxy en Apache que moviera desde /uploads/ hacia unix:/../../nginx.http.sock|http://localhost/discourse/uploads
-
Ahora lo más extraño: cuando el cliente envía solicitudes que contienen /uploads/default/ o /discourse/uploads/default/ (contenido estático), necesitamos seguir la solución del punto 1 descrita antes y redirigirlas ambas a
http://localhost/uploads/default/(sin el prefijo /discourse), mientras que otras solicitudes /uploads/ o /discourse/uploads/ que no contienen el prefijo /default en la ruta deben redirigirse ahttp://localhost/discourse/uploads/(notar que sin la ruta default significa que son llamadas a servicios web)
Con todas estas 9 reglas de proxy que insertamos, todo vuelve a funcionar correctamente incluso bajo la ruta /discourse. Pero nos pareció extremadamente extraño que tuviéramos que escribir todo esto para que todo volviera a funcionar.
¿Estamos haciendo algo mal?
¿Existe algún otro método inteligente para gestionar esta situación?
=== EDICIÓN ===
Omití otra cosa que quizás esté relacionada:
Cuando el usuario intenta subir una imagen personalizada para usar como avatar personal, la subida es correcta y se muestra correctamente la miniatura de la imagen.
Pero cuando se presiona el botón Guardar cambios y se recarga la página, el avatar vuelve al avatar predeterminado del usuario
Al revisar el archivo
produciton.log, muestra que el error es Código 418.Otras subidas de imágenes funcionan bien.
Gracias de antemano por las respuestas y por su increíble trabajo!