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 Mi Piace
Thanks, I missed this bit:
1 Mi Piace
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 Mi Piace
You just need to follow this guide here in the OP and you will get a functional object storage configuration.
3 Mi Piace
Setting those variables makes them unavailable from the UX. You must set them as described here rather than the ux.
2 Mi Piace
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 Mi Piace
Are those the urls you put in the env variables described in the OP? And are they https?
1 Mi Piace
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 Mi Piace
Ho configurato Caricamenti S3 e l’archiviazione degli oggetti come descritto qui nell’OP, ma senza una CDN.
Per la variabile DISCOURSE_S3_CDN_URL, ho questo:
https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com
Tutto sembra a posto, inclusi i backup, tuttavia, nella console questo errore appare quando si avvia una risposta a un post:
L’URL della richiesta nell’errore è in realtà una stringa di due URL che sembra essere 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 Mi Piace
Una CDN è obbligatoria affinché funzioni correttamente.
4 Mi Piace
Mi trovo anch’io in questa situazione con un object store configurato (minio) ma senza CDN. È un caso d’uso che potrebbe essere supportato?
Da quello che vedo finora nei miei test, solo il file JS markdown-it-bundle ha problemi, poiché punta all’URL sbagliato: DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Sembra effettivamente un bug per questo, se imposto la variabile DISCOURSE_CDN_URL, punta ancora all’URL sbagliato in questa forma DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Dovrebbe puntare a DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Altri asset JS puntano all’URL corretto.
Immagino, da quello che dici, che avrò altri problemi che non ho ancora identificato. Forse puoi darmi maggiori informazioni su cosa potrebbe andare storto?
Se ho capito bene, gli asset JS sono sull’object store, i fogli di stile dovrebbero essere su una CDN. Senza una CDN, i fogli di stile potrebbero essere distribuiti dall’app come al solito? (da quello che vedo è così)
Grazie per il tuo aiuto.
3 Mi Piace
Questo non è un caso d’uso supportato secondo l’OP:
1 Mi Piace
Cari tutti,
Ho configurato un nuovo server Discourse con Lightsail, utilizzando questa guida per i caricamenti e i backup su S3 setting-up-file-and-image-uploads-to-s3
Dopo la configurazione, ho ricevuto l’errore “Il bucket non consente ACL” sullo schermo quando carico un’immagine
Ecco la mia policy per 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/*"
]
}
]
}
E questa è la mia configurazione di accesso pubblico per il bucket S3:
Qualcuno potrebbe aiutarmi a risolvere questo problema, per favore?
Grazie mille
Saluti,
Quang
3 Mi Piace
Il mio sito di staging dovrebbe usare lo stesso bucket S3 del mio sito di produzione?
1 Mi Piace
No, sarebbe molto insicuro e potrebbe eliminare file che dovrebbero ancora esistere nell’altro ambiente e modificare file dall’altro ambiente (il che potrebbe causare file mancanti, file errati e così via).
Sia i bucket che le credenziali dovrebbero essere diversi (e le credenziali di staging non dovrebbero avere accesso al bucket di produzione, specialmente per quanto riguarda le operazioni di scrittura ed eliminazione).
Forse c’è un modo utilizzando percorsi con credenziali diverse per ciascun percorso, ma le probabilità di farsi male sono elevate, quindi consiglio di utilizzare bucket separati.
5 Mi Piace
DISCOURSE_CDN_URL e DISCOURSE_S3_CDN_URL devono essere separati anche loro?
1 Mi Piace
Lo presumo, 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 Mi Piace
Ciao a tutti, sono abbastanza nuovo a S3, quindi non sono del tutto sicuro di come formulare questo, ma ci proverò al meglio. Ho appena iniziato a usare S3 per caricamenti e backup e ho usato Discourse Connect per consentire l’accesso ad altre parti del mio sito, ma ora le immagini del profilo non funzionano. Credo che questo abbia a che fare con le policy CORS, ma non sono sicuro di dove potrei configurarle. Idealmente vorrei metterle in whitelist per forum.domain.tld e domain.tld - o anche un wildcard su tutti i sottodomini andrebbe bene. È qualcosa che dovrei impostare in Discourse, o dove esattamente? Sto usando Vultr object storage se questo fa differenza.
1 Mi Piace
È possibile abilitare il versioning sul bucket S3 files? AWS Backup è il modo consigliato per eseguire il backup dei bucket S3 per Discourse?
1 Mi Piace
Sì.
L’utilizzo del versioning o la sincronizzazione con un’altra regione sono tutte buone strategie.
4 Mi Piace