È impostato nel blocco di configurazione di esempio per Vultr nell’OP. Copia e incolla nel tuo file app.yml e modifica i campi necessari.
2 Mi Piace
Grazie, mi sono perso questa parte:
1 Mi Piace
Non sta andando molto liscio per me, scusa se rispondo così tante volte.
Se faccio quanto sopra, devo ignorare le impostazioni del pannello di amministrazione per S3 e i backup?
O le impostazioni del pannello di amministrazione devono essere configurate anch’esse?
1 Mi Piace
Basta seguire questa guida nell’OP e otterrai una configurazione di object storage funzionante.
3 Mi Piace
Impostare quelle variabili le rende non disponibili dall’interfaccia utente. Devi impostarle come descritto qui, anziché nell’interfaccia utente.
2 Mi Piace
Penso che (per la maggior parte?) funzioni ora, ma questa content security policy script src è sicura?
Sto utilizzando AWS per due contenitori S3 (per upload e backup) e due CDN CloudFront (per file e asset). Quando uso i miei CNAME personalizzati per le CDN CloudFront, ricevo diversi errori di rete relativi a script-src nel browser durante il caricamento di Discourse. Non ci sono più errori dopo aver aggiunto quelle voci alla mia CSP.
1 Mi Piace
Sono questi gli URL che hai inserito nelle variabili d’ambiente descritte nell’OP? E sono in https?
1 Mi Piace
Sì, non ricevo avvisi relativi a script-src quando inserisco i due URL d23whatever.cloudfront.net nelle variabili d’ambiente. Quando inserisco i miei URL personalizzati, ovvero community-cdn.mydomain e files-cdn.mydomain, nelle variabili d’ambiente, è in quel momento che ricevo questi avvisi script-src. E a quanto pare, lo script JS di Stripe continua a generare questo avviso, anche se è già incluso nel mio 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