Para un foro completamente privado (sin acceso anónimo), la falta de una opción de medios seguros en la configuración predeterminada de almacenamiento local me parece un gran descuido. No me sorprendería que mucha gente que administra foros privados no se dé cuenta de que todos los archivos adjuntos de sus publicaciones son accesibles públicamente (si se conoce la URL). Si el texto de mi publicación no puede ser accedido anónimamente, intuitivamente pensaría que los archivos adjuntos de la publicación tampoco deberían poder serlo.
¿Vale la pena abrir un issue solicitando esto para ver qué tipo de apoyo recibiría? ¿Existe ya alguno? Este único problema es actualmente un obstáculo decisivo para nuestro pequeño grupo con recursos limitados, que está intentando desplegar Discourse en un entorno donde ya contamos con el hardware de alojamiento y no queremos pagar por almacenamiento en la nube (especialmente a los precios de AWS S3) solo para asegurarnos de que nuestros medios no sean visibles de forma anónima.
Además, disculpen la posible ingenuidad de esta pregunta. Pero ya existe soporte para buckets distintos para las cargas y las copias de seguridad, ¿verdad? ¿Sería difícil soportar un tercer bucket para cargas seguras? Las cargas públicas irían al bucket público, las cargas seguras al bucket seguro y no serían necesarias ACLs individuales para cada objeto. Y si cambia el estado de seguridad de un objeto, ¿podría simplemente moverse entre buckets?
Creo que es bastante trabajo. Al menos un día de trabajo, pero ¿quizás una semana?
La alojamiento de Cdck, que financia el desarrollo, utiliza S3 para las subidas, por lo que solo interesan los sitios autoalojados que requieren inicio de sesión y no tienen presupuesto para S3.
Si tus usuarios ven enlaces para compartir tus recursos, podrían simplemente descargarlos para compartirlos. No parece ser un gran problema.
No estoy loco de pensar que es extraño que el texto de las publicaciones esté protegido pero los archivos adjuntos no, ¿verdad?
Sin embargo, hay una gran diferencia entre compartir de forma intencional y accidental. Obviamente, no hay una forma real de prevenir lo primero. Pero lo segundo puede ocurrir ahora mismo simplemente porque la gente no entiende la tecnología subyacente. Considera las notificaciones por correo electrónico para publicaciones que incluyen enlaces a imágenes adjuntas que se reenvían inocentemente a personas que no son miembros. Una opción para omitir los archivos adjuntos en los correos electrónicos, que no esté vinculada a la funcionalidad de medios seguros, podría ser una buena alternativa en ese caso.
Incluso cuando las personas comparten intencionalmente enlaces de archivos adjuntos, podrían haber olvidado simplemente que provenían de una categoría protegida. Pero en un mundo ideal, el enlace del archivo adjunto debería ser inútil para cualquier persona sin acceso a esa categoría.
Un error actual o futuro en una de las implementaciones de S3 también podría permitir potencialmente la enumeración anónima de los recursos en un bucket o la capacidad de adivinar y forzar bruto las URLs de los objetos. En un mundo ideal, querría que mi interfaz S3 local estuviera protegida por un firewall frente a Internet en general, de modo que solo el servidor de Discourse pudiera acceder a ella directamente.
No estás loco; implementar cargas seguras para configuraciones que no son de S3 definitivamente no es algo en lo que me oponga a trabajar. Simplemente no tenemos urgencia ni impulso para desarrollar esta función y el cambio no es trivial.
Ocasionalmente tenemos pasantes y proyectos de audición; este es sin duda un tipo de proyecto que podría encajar en alguna de esas categorías.
Tengo un pequeño truco que creo que proporcionaría cargas seguras para sitios que requieren inicio de sesión.
Básicamente, configuras Authentication Based on Subrequest Result | NGINX Documentation para las cargas. El único problema es que no puedo encontrar una URL que devuelva un 403/401 cuando la opción de “requiere inicio de sesión” está activada, por lo que acceder a una carga cuando no has iniciado sesión genera un error 500. Esto solo ocurriría si alguien tuviera una URL de carga e intentara acceder a ella sin haber iniciado sesión, así que no parece tan grave.
Es algo así:
# JP
location = /auth {
internal;
proxy_pass http://discourse/categories;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
# END JP
location ~ ^/uploads/ {
auth_request /auth; #$JP
# NOTA: es realmente molesto que no podamos definir encabezados
# a nivel superior e heredarlos.
#
No tenemos planes de crear una funcionalidad de buckets distinta para cargas seguras, ni tampoco de hacer que las cargas seguras funcionen con configuraciones que no sean S3 o configuraciones sin ACLs. Podríamos considerar hacerlo en el futuro si hay suficiente demanda de este trabajo hasta el punto en que tenga sentido para nosotros dedicar tiempo y recursos a este esfuerzo.
¿Por qué está usando https://hashhackersforum.s3.us-east-2.amazonaws.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc en lugar de https://forum.cdn.hashhackers.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc, si ya ingresé la URL del CDN correctamente?
No me importa ignorarlo, pero tenemos activado el contenido multimedia seguro, lo que significa que no es posible utilizar una CDN. Es probable que este mensaje no deba mostrarse en sitios con secure_media activado.
Eso es genial. No me quedó claro que Discourse tratara los activos estáticos de manera diferente. Creo que necesito volver a leer todos los hilos aquí.
Después de actualizar a la versión 2.8.0.beta1, mis insignias que usan URLs de S3 autenticadas dejan de funcionar. Antes de la actualización funcionaba correctamente.
Verifiqué la tabla uploads y el valor de la columna secure es true.
Ah… otra vez más un lugar que está implementando cargas seguras cuando no debería. Las insignias no deben marcarse como seguras, ya que son esencialmente imágenes públicas, como avatares, logotipos de categorías y otros elementos. Necesitaré realizar una corrección para asegurarme de que las imágenes de insignias no se marquen como seguras, así como un script de migración que corrija las que ya están marcadas como seguras.
Me sorprende que esto te estuviera funcionando en absoluto; nada en la versión 2.8.0 debería haber afectado esto.
Gracias por tu respuesta. Es mi primera vez usando Ruby y me encanta lo clara que puede ser este lenguaje. Después de varias horas depurando, creo que he encontrado dónde mirar. Supongo que hice lo contrario de lo que dijiste Añadí algunas líneas en el modelo Badge y ahora puede cargar las imágenes. También veo que tenemos una bandera for_site_setting allí. Creo que se basa en esta información para ajustar el ACL de los objetos en S3, y establece false para esa columna.
app/models/badge.rb
def image_url
if image_upload_id.present?
return upload_cdn_path(image_upload.url) if !image_upload.url.include?(SiteSetting.Upload.absolute_base_url)
uri = URI.parse(image_upload.url)
Rails.application.routes.url_for(
controller: "uploads",
action: "show_secure",
path: uri.path[1..-1],
only_path: true
)
end
end
Voy a revisar qué cambios habrá en la próxima actualización para aprender más al respecto.
¿Podrías decirme cuál es la mejor versión para usar en producción?
¡Gracias!
Espero poder contribuir más a la base de código en el futuro.
El cambio que hiciste en el modelo de insignias definitivamente funcionará, y es genial que hayas logrado implementarlo en tu primer intento usando Ruby. Aunque voy a proceder a solucionar el problema central por el cual las insignias no deberían estar marcadas como seguras.
Nuestra rama tests-passed es la mejor versión para usar en producción, ya que obtendrá todas las correcciones más recientes tan pronto como estén disponibles, aunque algunas personas pueden preferir quedarse en la rama beta, que recibe correcciones y cambios cada pocas semanas más o menos.
Te avisaré cuando tenga lista la corrección para que las insignias no se marquen como seguras.
…pero me pregunto si el problema está relacionado con tu comentario aquí.
¿Se permite que los usuarios suban avatares cuando la carga de medios seguros está activada? Por ahora estoy recibiendo un error, pero me pregunto si esto se debe a que los avatares se suben al mismo bucket donde no se permite el acceso público…
1 me gusta
Canapin
(Coin-coin le Canapin)
Separó este tema
126
Recientemente cambié el nombre de «medios seguros» y la configuración relacionada a «cargas seguras», ya que no solo se aplica a imágenes/vídeos, etc., y todo el mundo se refiere a ello como cargas seguras de todos modos. El commit principal relevante está aquí:
El hilo principal de este tema se ha actualizado para reflejar esto.
Añadí algunas líneas en el modelo Badge y ahora puede cargar las imágenes. También veo que tenemos una bandera for_site_setting allí. Creo que se basa en esta información para ajustar el ACL de los objetos en S3, y establece false para esa columna.