Dado que Discourse no utiliza Apache, ¿cómo se puede proteger con contraseña, por ejemplo, un entorno de staging (un droplet de Digital Ocean con Discourse Docker) como se haría con .htaccess (Apache)?
No hay Apache, pero NGINX se está ejecutando dentro del contenedor de Discourse. Este tema puede ayudar:
Perfecto, gracias @david 
Acabo de añadirlo, pero ahora cada imagen de https://cdn-uploads.example.com y https://cdn-origin.example.com requiere ingresar la contraseña de autenticación. ¿Hay alguna manera de proteger solo https://discourse.example.com?
De lo contrario, ahora obtengo esto:
No estoy seguro exactamente de cómo lograr eso, pero quizás alguien más intervenga si tiene algunas ideas. Debería ser posible con algunos ajustes en la configuración de nginx.
Como solución temporal, y dado que este es un servidor de staging, ¿podrías simplemente desactivar la CDN? Si usas el mismo dominio para los activos, se enviará automáticamente la cabecera de autenticación, por lo que no necesitarás ingresar la contraseña de autenticación nuevamente.
Sí, claro, si esa es la aproximación recomendada para un entorno de staging cuando se utilizan buckets de S3 para copias de seguridad y subidas, así como CloudFront como CDN para subidas y origen en producción.
¿Realmente no es necesario tener todo eso para un entorno de staging?
Este cambio en nginx definitivamente no debería afectar las subidas a S3 ni la CDN de S3. NGINX no está involucrado en absoluto en ese proceso. Había asumido que estabas usando subidas locales con una CDN.
La situación ideal es configurar el sitio de staging de manera idéntica al sitio de producción.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east-1
DISCOURSE_S3_ACCESS_KEY_ID: XXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_SECRET_ACCESS_KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_CDN_URL: https://cdn-uploads.example.com
DISCOURSE_S3_BUCKET: example-uploads
DISCOURSE_S3_BACKUP_BUCKET: example-backup
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_CDN_URL: https://cdn-origin.example.com
Y el dominio principal para la etapa de pruebas es actualmente https://staging.example.com
Sin embargo, aún se me solicita autenticación en cada solicitud desde cdn-origin con el código propuesto al acceder a https://staging.example.com
Actualización para quienes están experimentando el mismo problema:
Tuvimos que permitir los encabezados de autorización en CloudFront para cdn-origin.
Parece que no se me solicitó autenticación para cdn-uploads.
Ya funciona.
Activo la opción de inicio de sesión obligatorio en el sitio de staging. Puedes hacerlo mediante una variable de entorno en app.yml para que sea persistente.
No es lo suficientemente bueno si Google o cualquier otro encuentra el sitio. De todos modos, ahora funciona.
Verán el sitio, pero no podrán ver ningún contenido. ¿Verdad?
En nuestro caso, también tenemos que poder ver cómo reacciona el sitio ante usuarios anónimos. Bien, ahora funciona con basic_auth.
¡Bueno, me has hecho repensar cómo hago esto!
Hola @Terrapop
Aquí tienes una idea para ti, y así es como lo hacemos nosotros.
Si ejecutas tu entorno de staging detrás de Apache2 (o nginx) como un proxy inverso, puedes configurar reglas de acceso en el proxy inverso de la misma manera que lo harías con .htaccess, tal como estás acostumbrado.
Hay una infinidad de ventajas al ejecutar Discourse detrás de un proxy inverso, y la facilidad de control de acceso es solo uno de los beneficios.
Espero que esto te ayude.
¿Existe una guía paso a paso infalible para Nginx? Estamos alojando en DigitalOcean a través de un Droplet y Docker.
Hola @Terrapop
Hay muchos excelentes tutoriales en Meta sobre cómo configurar Discourse en una configuración de “dos contenedores” detrás de un proxy inverso.
Puedes intentar buscar en Meta:
two container reverse proxy
Espero que esto te ayude.
Ten en cuenta que, para simplemente hacer pruebas de staging, muchas personas no configuran “dos contenedores” y solo lo hacen en producción; pero si deseas realizar staging “exactamente como en producción”, entonces la configuración de “dos contenedores” es definitivamente una excelente opción. Sin embargo, no necesitas “dos contenedores” para ejecutar una aplicación web detrás de un proxy inverso. Regularmente ejecuto aplicaciones web de ROR y Docker detrás de un proxy inverso tanto en producción como en desarrollo.
Hola. Solo quiero saber cómo habilitaste correctamente los encabezados de autorización en CloudFront. Agregué “auth_basic” en app.yml como se indicó anteriormente. La protección con contraseña funciona al navegar desde el escritorio, pero obtengo esto al navegar desde un dispositivo móvil (después de ingresar el usuario y la contraseña):
Tengo esto en mi “cdn-origin”:
Política “whitelist-authorization-headers”:
Soy bastante nuevo en CloudFront y es posible que solo me esté perdiendo algo muy obvio (para la configuración móvil).