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 « J'aime »
Thanks, I missed this bit:
1 « J'aime »
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 « J'aime »
You just need to follow this guide here in the OP and you will get a functional object storage configuration.
3 « J'aime »
Setting those variables makes them unavailable from the UX. You must set them as described here rather than the ux.
2 « J'aime »
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 « J'aime »
Are those the urls you put in the env variables described in the OP? And are they https?
1 « J'aime »
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 « J'aime »
J’ai configuré les téléchargements S3 et le stockage d’objets comme décrit ici dans le message d’origine, mais sans CDN.
Pour la variable DISCOURSE_S3_CDN_URL, j’ai ceci :
https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com
Tout semble bien, y compris les sauvegardes, cependant, dans la console cette erreur apparaît lorsqu’une réponse à un message est commencée :
L’URL de la requête dans l’erreur est en fait une chaîne de deux URL, ce qui semble être la cause ?
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 « J'aime »
Un CDN est obligatoire pour que cela fonctionne correctement.
4 « J'aime »
Je suis également dans cette situation avec un magasin d’objets configuré (minio) mais pas de CDN. Est-ce un cas d’utilisation qui pourrait être pris en charge ?
D’après ce que je vois jusqu’à présent dans mes tests, seul le fichier js markdown-it-bundle pose problème car il pointe vers la mauvaise URL - DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Cela ressemble en fait à un bug pour celui-ci, si je définis la variable DISCOURSE_CDN_URL, il pointe toujours vers la mauvaise URL sous la forme DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Il devrait pointer vers DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Les autres actifs js pointent vers la bonne URL.
Je suppose que d’après ce que vous dites, j’aurai d’autres problèmes que je n’ai pas encore identifiés. Peut-être pouvez-vous me donner plus d’informations sur ce qui pourrait mal se passer ?
Si je comprends bien, les actifs js sont sur le magasin d’objets, les feuilles de style devraient être sur un CDN. Sans CDN, les feuilles de style pourraient-elles être livrées par l’application comme d’habitude ? (d’après ce que je vois, c’est le cas)
Merci de votre aide.
3 « J'aime »
Ce n’est pas un cas d’utilisation pris en charge, selon l’OP :
1 « J'aime »
Bonjour à tous,
J’ai configuré un nouveau serveur Discourse avec Lightsail, en utilisant ce guide pour les téléchargements et les sauvegardes S3 setting-up-file-and-image-uploads-to-s3
Après la configuration, j’ai obtenu l’erreur suivante à l’écran lors du téléchargement d’une image : « Le compartiment n’autorise pas les ACL »
Voici ma politique pour 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/*"
]
}
]
}
Et voici mon accès public configuré pour le compartiment S3 :
Quelqu’un pourrait-il m’aider à résoudre ce problème, s’il vous plaît ?
Merci beaucoup
Cordialement,
Quang
3 « J'aime »
Mon site de staging doit-il utiliser le même compartiment S3 que mon site de production ?
1 « J'aime »
Non, ce serait très dangereux et cela pourrait supprimer des fichiers qui devraient toujours exister dans l’autre environnement et modifier des fichiers de l’autre environnement (ce qui pourrait entraîner des fichiers manquants, des fichiers incorrects, etc.).
Les deux buckets ainsi que les identifiants devraient être différents (et les identifiants de staging ne devraient pas avoir accès au bucket de production, en particulier en ce qui concerne les opérations d’écriture et de suppression).
Il existe peut-être une solution utilisant des chemins avec des identifiants différents pour chaque chemin, mais les risques de se tirer une balle dans le pied sont élevés, je conseille donc d’utiliser des buckets séparés.
5 « J'aime »
DISCOURSE_CDN_URL et DISCOURSE_S3_CDN_URL doivent-ils également être séparés ?
1 « J'aime »
Je suppose que oui, car si vos domaines/URL de staging et de production sont différents (ils le sont, n’est-ce pas ?), alors DISCOURSE_CDN_URL (qui finit par pointer vers le fournisseur de CDN, qui pointe vers le domaine de votre site web) devrait être différent pour le staging et la production. La même logique s’applique à DISCOURSE_S3_CDN_URL (car des buckets différents devraient avoir des URL différentes).
4 « J'aime »
Salut à tous, je suis assez nouveau sur S3, donc je ne suis pas tout à fait sûr de la façon de formuler cela, mais je vais faire de mon mieux. J’ai donc récemment commencé à utiliser S3 pour les téléchargements et les sauvegardes, et j’utilisais Discourse Connect pour permettre les connexions sur d’autres parties de mon site, mais maintenant les images de profil ne fonctionnent plus. Je pense que cela a à voir avec les politiques CORS, mais je ne suis pas sûr où je pourrais le configurer. Idéalement, je voudrais le mettre sur liste blanche pour forum.domain.tld et domain.tld - ou un joker sur tous les sous-domaines fonctionnerait aussi. Est-ce quelque chose que je configurerais dans Discourse, ou où exactement ? J’utilise le stockage d’objets Vultr si cela fait une différence.
1 « J'aime »
La gestion des versions peut-elle être activée sur le compartiment S3 files ? AWS Backup est-il le moyen recommandé pour sauvegarder les compartiments S3 pour Discourse ?
1 « J'aime »
Oui.
L’utilisation de la gestion des versions ou la synchronisation vers une région différente sont toutes de bonnes stratégies.
4 « J'aime »