Configurer un fournisseur de stockage d'objets compatible S3 pour les téléchargements

C’est défini dans le bloc de configuration d’exemple pour Vultr dans l’OP. Copiez et collez-le dans votre app.yml et ajustez les champs nécessaires.

2 « J'aime »

Merci, j’avais manqué ce détail :

1 « J'aime »

Cela ne se passe pas très bien pour moi, désolé de répondre autant de fois.

Si je fais ce qui précède, dois-je ignorer les paramètres du panneau d’administration pour S3 et les sauvegardes ?

Ou les paramètres du panneau d’administration doivent-ils également être configurés ?

1 « J'aime »

Il vous suffit de suivre ce guide dans le message d’origine (OP) et vous obtiendrez une configuration de stockage d’objets fonctionnelle.

3 « J'aime »

Définir ces variables les rend indisponibles dans l’interface utilisateur. Vous devez les configurer comme décrit ici, et non via l’interface utilisateur.

2 « J'aime »

Je pense que cela fonctionne (en grande partie ?) maintenant, mais cette content security policy script src est-elle sûre ?

J’utilise AWS pour deux conteneurs S3 (pour les uploads et les sauvegardes) et deux CDN CloudFront (pour les fichiers et les ressources). Lorsque j’utilise mes propres CNAME pour les CDN CloudFront, je rencontre de nombreuses erreurs réseau script-src dans mon navigateur lors du chargement de Discourse. Plus d’erreurs après avoir ajouté ces entrées à ma CSP.

1 « J'aime »

S’agit-il des URL que vous avez saisies dans les variables d’environnement décrites dans le message original ? Et sont-elles en https ?

1 « J'aime »

Oui, je n’ai pas d’avertissements script-src lorsque j’ajoute les deux URL d23whatever.cloudfront.net dans les variables d’environnement. C’est lorsque j’ajoute mes URL personnalisées, à savoir community-cdn.mydomain et files-cdn.mydomain, dans les variables d’environnement que j’obtiens ces avertissements script-src. Et apparemment, le script Stripe continue de me générer cet avertissement, même s’il est inclus dans mon 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 »