Está establecido en el bloque de configuración de ejemplo para Vultr en el mensaje original. Copia y pega en tu archivo app.yml y ajusta los campos necesarios.
2 Me gusta
Gracias, me perdí esta parte:
1 me gusta
Esto no me está yendo muy bien, disculpa que responda tantas veces.
Si hago lo anterior, ¿debería ignorar la configuración del panel de administración para S3 y las copias de seguridad?
¿O también se debe configurar la configuración del panel de administración?
1 me gusta
Solo necesitas seguir esta guía en el mensaje original y obtendrás una configuración funcional de almacenamiento de objetos.
3 Me gusta
Establecer esas variables las hace inaccesibles desde la UX. Debes configurarlas como se describe aquí en lugar de en la UX.
2 Me gusta
Creo que ahora funciona (en su mayoría), pero ¿es seguro este script-src de la política de seguridad de contenido?
Estoy utilizando AWS para dos contenedores S3 (para cargas y copias de seguridad) y dos CDNs de CloudFront (para archivos y recursos). Cuando uso mis propios CNAMEs para las CDNs de CloudFront, obtengo varios errores de red en script-src en mi navegador al cargar Discourse. Ya no hay errores después de agregar esas entradas a mi CSP.
1 me gusta
¿Son esas las URLs que pusiste en las variables de entorno descritas en la publicación original? ¿Y son https?
1 me gusta
Sí, no recibo advertencias de script-src cuando incluyo las dos URLs d23whatever.cloudfront.net en las variables de entorno. Sin embargo, cuando uso mis propias URLs, es decir, community-cdn.mydomain y files-cdn.mydomain, en las variables de entorno, es cuando aparecen esas advertencias de script-src. Y, al parecer, el script de Stripe sigue generando esta advertencia, aunque ya esté incluido en mi script src de la política de seguridad de contenido.
2 Me gusta
Configuré Cargas S3 y almacenamiento de objetos como se describe aquí en el OP, pero sin una CDN.
Para la variable DISCOURSE_S3_CDN_URL, tengo esto:
https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com
Todo parece estar bien, incluidas las copias de seguridad, sin embargo, en la consola aparece este error cuando se inicia una respuesta a una publicación:
La URL de la solicitud en el error es en realidad una cadena de dos URL, ¿lo que parece ser la causa?
https://mydiscourse.com/t/uploads-test-for-s3/79/https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com/assets/markdown-it-bundle-a7328b73d3e7b030770eab70f10bdb0af655b3d8fa929bc49f1ad04c4cdaa198.br.js
2 Me gusta
Una CDN es obligatoria para que funcione correctamente.
4 Me gusta
También estoy en esta situación con un almacén de objetos configurado (minio) pero sin CDN. ¿Es un caso de uso que podría ser compatible?
Por lo que estoy viendo hasta ahora en mis pruebas, solo el archivo JS markdown-it-bundle tiene problemas, ya que apunta a la URL incorrecta: DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
De hecho, parece un error para este, si establezco la variable DISCOURSE_CDN_URL, todavía apunta a la URL incorrecta en esta forma DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Debería apuntar a DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Otros activos JS apuntan a la URL correcta.
Supongo que, por lo que dices, tendré otros problemas que aún no he identificado. ¿Quizás puedas darme más información sobre lo que podría salir mal?
Si lo entiendo bien, los activos JS están en el almacén de objetos, las hojas de estilo deberían estar en una CDN. Sin una CDN, ¿podrían las hojas de estilo ser entregadas por la aplicación como de costumbre? (por lo que estoy viendo, es el caso)
Gracias por tu ayuda.
3 Me gusta
Ese no es un caso de uso compatible según el OP:
1 me gusta
Estimados todos,
Configuré un nuevo servidor de Discourse con Lightsail, utilizando esta guía para cargas y copias de seguridad de S3 configuración-de-cargas-de-archivos-e-imágenes-a-s3
Después de la configuración, apareció el error “El bucket no permite ACL” en la pantalla cuando subo una imagen.
Aquí está mi política para S3:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:GetObjectVersionTagging",
"s3:CreateBucket",
"s3:GetObjectAcl",
"s3:GetBucketObjectLockConfiguration",
"s3:PutLifecycleConfiguration",
"s3:GetObjectVersionAcl",
"s3:PutObjectTagging",
"s3:DeleteObject",
"s3:DeleteObjectTagging",
"s3:GetBucketPolicyStatus",
"s3:GetObjectRetention",
"s3:GetBucketWebsite",
"s3:ListJobs",
"s3:DeleteObjectVersionTagging",
"s3:GetObjectLegalHold",
"s3:GetBucketNotification",
"s3:PutBucketCORS",
"s3:GetReplicationConfiguration",
"s3:ListMultipartUploadParts",
"s3:PutObject",
"s3:GetObject",
"s3:DescribeJob",
"s3:PutObjectVersionAcl",
"s3:GetAnalyticsConfiguration",
"s3:GetObjectVersionForReplication",
"s3:GetLifecycleConfiguration",
"s3:GetAccessPoint",
"s3:GetInventoryConfiguration",
"s3:GetBucketTagging",
"s3:GetBucketLogging",
"s3:ListBucketVersions",
"s3:ReplicateTags",
"s3:ListBucket",
"s3:GetAccelerateConfiguration",
"s3:GetBucketPolicy",
"s3:GetEncryptionConfiguration",
"s3:GetObjectVersionTorrent",
"s3:AbortMultipartUpload",
"s3:PutBucketTagging",
"s3:GetBucketRequestPayment",
"s3:GetAccessPointPolicyStatus",
"s3:GetObjectTagging",
"s3:GetMetricsConfiguration",
"s3:PutObjectAcl",
"s3:GetBucketPublicAccessBlock",
"s3:ListBucketMultipartUploads",
"s3:ListAccessPoints",
"s3:PutObjectVersionTagging",
"s3:GetBucketVersioning",
"s3:GetBucketAcl",
"s3:GetObjectTorrent",
"s3:GetAccountPublicAccessBlock",
"s3:ListAllMyBuckets",
"s3:GetBucketCORS",
"s3:GetBucketLocation",
"s3:GetAccessPointPolicy",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::mybucket-upload",
"arn:aws:s3:::mybucket-upload/*",
"arn:aws:s3:::mybucket-backup",
"arn:aws:s3:::mybucket-backup/*"
]
}
]
}
Y aquí está mi configuración de acceso público para el bucket de S3:
¿Alguien podría ayudarme a resolver este problema, por favor?
Muchas gracias
Saludos,
Quang
3 Me gusta
¿Debería mi sitio de staging usar el mismo bucket de S3 que mi sitio de producción?
1 me gusta
No, eso sería muy inseguro y podría eliminar archivos que aún deberían existir en el otro entorno y cambiar archivos del otro entorno (lo que podría causar archivos faltantes, archivos incorrectos, etc.).
Tanto los buckets como las credenciales deben ser diferentes (y las credenciales de staging no deben tener acceso al bucket de producción, especialmente en lo que respecta a las operaciones de escritura y eliminación).
Quizás haya una manera de usar rutas con credenciales diferentes para cada ruta, pero las posibilidades de autolesionarse son altas, por lo que aconsejo usar buckets separados.
5 Me gusta
¿DISCOURSE_CDN_URL y DISCOURSE_S3_CDN_URL también necesitan estar separados?
1 me gusta
Supongo que sí, porque si tus dominios/URL de staging y producción son diferentes (lo son, ¿verdad?), entonces DISCOURSE_CDN_URL (que termina apuntando al proveedor de CDN, que apunta al dominio de tu sitio web) se espera que sea diferente para staging y producción. La misma lógica se aplica a DISCOURSE_S3_CDN_URL (porque diferentes buckets deberían tener URL diferentes).
4 Me gusta
Hola a todos, soy bastante nuevo en S3, así que no estoy del todo seguro de cómo plantear esto, pero haré mi mejor esfuerzo. Así que, acabo de cambiar a usar S3 para cargas y copias de seguridad y he estado usando Discourse Connect para permitir inicios de sesión en otras partes de mi sitio, pero ahora las imágenes de perfil no funcionan. Creo que esto tiene que ver con las políticas CORS, pero no estoy seguro de dónde podría configurarlo. Idealmente, me gustaría incluirlo en la lista blanca para forum.domain.tld y domain.tld, o un comodín en todos los subdominios también funcionaría. ¿Es esto algo que configuraría en Discourse, o dónde exactamente? Estoy usando el almacenamiento de objetos de Vultr si eso marca la diferencia.
1 me gusta
¿Se puede habilitar el control de versiones en el bucket S3 files? ¿Es AWS Backup la forma recomendada de hacer copias de seguridad de los buckets S3 para Discourse?
1 me gusta
Sí.
Usar el versionado o sincronizar a una región diferente son todas buenas estrategias.
4 Me gusta