It’s set in the example configuration block for Vultr in the OP. Copy and paste into your app.yml and adjust the necessary fields.
2 Me gusta
Thanks, I missed this bit:
1 me gusta
This isn’t going smoothly for me, sorry to reply so many times.
If I do the above, should I ignore the admin panel settings for s3 and backups?
Or should admin panel settings be configured as well?
1 me gusta
You just need to follow this guide here in the OP and you will get a functional object storage configuration.
3 Me gusta
Setting those variables makes them unavailable from the UX. You must set them as described here rather than the ux.
2 Me gusta
I think it’s (mostly?) working now, but is this content security policy script src safe?
I’m using AWS for two S3 containers (for uploads & backups), and two CloudFront CDNs (for files & assets). When I use my own CNAMEs for the CloudFront CDNs, I get a bunch of script-src network errors in my browser when loading Discourse. No more errors after adding those entires to my CSP.
1 me gusta
Are those the urls you put in the env variables described in the OP? And are they https?
1 me gusta
Yes, I don’t have script-src warnings when I put the two d23whatever.cloudfront.net URLs in the env variables. When I put my custom URLs, i.e. community-cdn.mydomain and files-cdn.mydomain, in the env variables, that’s the time I get these script-src warnings. And apparently the stripe js is still giving me this warning even though it’s in my content security policy script src.
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