Tuve que dejar esto por ahora, ya que parecía que iba a funcionar, pero luego está sucediendo algo extraño con R2 en términos de codificación de contenido con los activos, ya sea al subirlos y no establecer la cabecera o algo más. Se atasca con un ‘Token no válido o inesperado’ dado el activo gz de algo como browser-detect-7af298cd000a967d2bdc01b04807eda2924a388584ea38ad84919b726283c2ed.gz.js. El rake s3:upload_assets parece estar funcionando, pero los archivos no se leen correctamente en el lado del navegador.
Realmente no entiendo por qué con AWS S3 está bien usar la URL del servidor local para los activos (no existen en nuestro bucket S3 existente para cargas), pero para el uso de R2 quiere usar DISCOURSE_S3_CDN_URL solo para los activos. Si pudiera forzar que los activos provengan de la URL del servidor, probablemente todo esto funcionaría.
EDITAR: Hablando en el CF, este parece ser el problema, y a partir de hoy por qué R2 no se puede usar con Discourse sin algunos cambios. Podría escribir un script en el paso del hook posterior para eliminar los activos gz, pero siento que ya estoy “fuera del camino” lo suficiente por hoy:
Los archivos que comprimes con gzip no se manejan correctamente actualmente en R2. Tienes que subir archivos sin comprimir. Cloudflare tiene compresión transparente, elige identidad, gzip o Brotli según lo que el cliente pueda manejar. Esto es una diferencia con S3.
¡Gracias por preparar esta guía! He tenido algo de éxito usando Minio.
Para cualquiera que intente configurarlo localmente con Docker Compose, puede indicarle a Docker que agregue un alias de nombre de host para que funcione como un subdominio, de la siguiente manera:
En este caso, configuraría DISCOURSE_S3_ENDPOINT=http://minio.mydomain.com:9000, DISCOURSE_S3_CDN_URL=//assets.minio.mydomain.com:9000, y configuraría su archivo local /etc/hosts/ para que apunte el subdominio a localhost.
Hola @Falco: ¿Se refiere esto a la forma en que la cabecera Content-Encoding: gzip funciona con su CDN de Spaces? ¿Eso suena similar a Cloudflare R2, en el sentido de que la ubicación del activo se hace igual que la CDN de carga, por lo que el gzip se rompe? Aquí está lo que sucede con R2 hoy.
¿Valdría la pena considerar un interruptor para ese comportamiento, es decir, servir activos desde el origen en lugar de siempre DISCOURSE_S3_CDN_URL? Estaré encantado de buscar cómo hacer esto, si se considerara como un posible cambio de configuración.
Eso es lo que debería suceder si omites la configuración de DISCOURSE_S3_CDN_URL, pero dado que es un caso límite extraño y un error potencialmente costoso, no es una configuración común.
Sí, puedo entender eso. Una nueva entrada booleana GlobalSetting S3_ORIGIN_ASSETS (o S3_BROKEN_PROXY_FUDGE ) por aquí, algo así como para cómo los scripts de prueba no están comprimidos permitirían que Digital Ocean Spaces y Cloudflare R2 funcionen con Discourse de inmediato, ¿lo cual es una buena característica adicional por poco esfuerzo? Quizás para futura consideración de todos modos.
Oh, vi en las notas de la versión 3.0.beta que se agregó algo. Lo intentaré, ¿a menos que no entienda para qué es? Podría permitir que Cloudflare R2 y Digital Ocean Spaces se usen con sus CDN haciendo cosas raras con gzip.
La configuración me permitió especificar el sitio local como origen, para evitar la necesidad de que los recursos de js estuvieran en el sitio S3 (en este caso, Cloudflare o Digital Ocean Spaces con CDN habilitado). Gracias a @david por el cambio, aunque esa no fuera la intención.
Hola a todos, ¿alguien sabe si esto podría estar relacionado con Discourse?
Este es el XML de los archivos que intentamos subir a nuestro almacenamiento S3 que antes ‘funcionaba con Discourse’:
<Error>
<Code>InvalidArgument</Code>
<Message>
Las solicitudes que especifican la encriptación del lado del servidor con claves administradas por AWS KMS requieren AWS Signature Version 4.
</Message>
<ArgumentName>Authorization</ArgumentName>
<ArgumentValue>null</ArgumentValue>
<RequestId>ID</RequestId>
<HostId>
ID
</HostId>
</Error>
esto parece haberse solucionado recientemente.
En el changelog del 16/03/2023 se enumera una corrección de errores para el manejo de archivos gzip.
Actualmente estamos ejecutando nuestro foro de discourse en discourse.aosus.org con R2 (aún no hemos ejecutado migrate_to_s3), ¡y parece estar bien! Sin problemas notables hasta ahora.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: "us-east-1" #alias to auto
#DISCOURSE_S3_INSTALL_CORS_RULE: true #debería ser compatible
DISCOURSE_S3_ENDPOINT: S3_API_URL
DISCOURSE_S3_ACCESS_KEY_ID: xxx
DISCOURSE_S3_SECRET_ACCESS_KEY: xxxx
DISCOURSE_S3_CDN_URL: tu url de cdn
DISCOURSE_S3_BUCKET: NOMBRE_DEL_BUCKET
¿Hay alguna forma de especificar un host separado para las copias de seguridad? Sería genial si fuera posible dejar R2 solo para cosas de CDN.
Es extraño que la configuración en ENV no se refleje en la interfaz de administración. ¿Se produce una anulación? ¿Las nuevas configuraciones de S3 en la interfaz de administración anularán las del entorno?
) por aquí, algo así como para cómo los 