J’ai dû mettre cela en pause pour l’instant, car il semblait que cela allait fonctionner, mais il y a quelque chose d’étrange qui se passe avec R2 en termes de codage de contenu avec les actifs, soit lors du téléchargement et de la non-définition de l’en-tête, soit autre chose. Cela échoue avec un message « Jeton invalide ou inattendu » étant donné l’actif gz de quelque chose comme browser-detect-7af298cd000a967d2bdc01b04807eda2924a388584ea38ad84919b726283c2ed.gz.js. Le rake s3:upload_assets semble fonctionner, mais les fichiers ne sont pas lus correctement du côté du navigateur.
Je ne comprends pas vraiment pourquoi avec AWS S3, il est acceptable d’utiliser l’URL du serveur local pour les actifs (ils n’existent pas dans notre bucket S3 existant pour les téléchargements), mais pour R2, il veut utiliser DISCOURSE_S3_CDN_URL uniquement pour les actifs. Si je pouvais forcer les actifs à provenir de l’URL du serveur, tout cela fonctionnerait probablement.
EDIT : En discutant sur le CF, cela semble être le problème, et à partir d’aujourd’hui, c’est pourquoi R2 ne peut pas être utilisé avec Discourse sans quelques modifications. Je pourrais créer un script dans l’étape post hook pour supprimer les actifs gz, mais je pense que je suis déjà « hors de la voie » assez loin pour une journée :
Les fichiers que vous compressez en gzip ne sont actuellement pas correctement gérés par R2. Vous devez télécharger des fichiers non compressés. Cloudflare a une compression transparente, ils choisissent l’identité, le gzip ou le Brotli en fonction de ce que le client peut gérer. C’est une différence par rapport à S3.
Excellent travail ! Et c’est un message clair de Cloudflare expliquant pourquoi cela ne fonctionnera pas. Merci beaucoup. Je vais copier cela dans le message initial bientôt.
Merci d’avoir préparé ce guide ! J’ai eu quelques succès en utilisant Minio.
Pour tous ceux qui essaient de le configurer localement avec Docker Compose, vous pouvez dire à Docker d’ajouter un alias d’hôte afin qu’il fonctionne comme un sous-domaine, comme ceci :
Dans ce cas, vous définiriez DISCOURSE_S3_ENDPOINT=http://minio.mydomain.com:9000, DISCOURSE_S3_CDN_URL=//assets.minio.mydomain.com:9000, et définiriez votre fichier local /etc/hosts/ pour pointer le sous-domaine vers localhost.
Salut @Falco - Est-ce que cela fait référence à la façon dont l’en-tête Content-Encoding: gzip fonctionne avec leur CDN Spaces ? Cela ressemble à Cloudflare R2, dans le sens où l’emplacement de l’actif est le même que le CDN de téléchargement, donc le gzip casse ? Voici ce qui se passe avec R2 aujourd’hui.
Il pourrait être intéressant d’envisager un interrupteur pour ce comportement, c’est-à-dire servir les actifs depuis l’origine plutôt que toujours DISCOURSE_S3_CDN_URL ? Je serais heureux d’aller voir comment faire cela, si cela pouvait être considéré comme un changement de configuration potentiel.
C’est ce qui devrait se passer si vous omettez la configuration de DISCOURSE_S3_CDN_URL, mais comme il s’agit d’un cas particulier étrange et d’une erreur potentiellement coûteuse, ce n’est pas une configuration courante.
Oui, je comprends. Une nouvelle entrée booléenne GlobalSetting S3_ORIGIN_ASSETS (ou S3_BROKEN_PROXY_FUDGE ) à peu près ici, un peu comme la façon dont les scripts de test ne sont pas compressés permettraient à Digital Ocean Spaces et à Cloudflare R2 de fonctionner avec Discourse dès la sortie de la boîte, ce qui est une belle fonctionnalité ajoutée pour peu d’effort ? Peut-être à considérer pour l’avenir de toute façon.
Oh, j’ai vu dans les notes de version 3.0.beta qu’il y a quelque chose de nouveau. Je vais essayer, à moins que je ne comprenne mal à quoi cela sert ? Cela pourrait permettre d’utiliser Cloudflare R2 et Digital Ocean Spaces avec leurs CDN en faisant ces trucs bizarres avec gzip.
Le paramètre m’a permis de spécifier le site local comme origine, pour contourner la nécessité que les ressources js soient sur le site S3 (dans ce cas Cloudflare ou Digital Ocean Spaces avec CDN activé). Merci à @david pour le changement, même si ce n’était pas l’intention.
Salut tout le monde, quelqu’un sait si cela pourrait être lié à Discourse ?
Voici le XML des fichiers que nous avons essayé de télécharger vers notre stockage S3 précédemment « fonctionnel avec Discourse » :
<Error>
<Code>InvalidArgument</Code>
<Message>
Les requêtes spécifiant le chiffrement côté serveur avec des clés gérées par AWS KMS nécessitent la version 4 de la signature AWS.
</Message>
<ArgumentName>Authorization</ArgumentName>
<ArgumentValue>null</ArgumentValue>
<RequestId>ID</RequestId>
<HostId>
ID
</HostId>
</Error>
cela semble avoir été corrigé récemment.
Dans le changelog du 16/03/2023, il est mentionné une correction de bug pour la gestion des fichiers gzip.
Nous exécutons actuellement notre forum discourse sur discourse.aosus.org avec R2 (nous n’avons pas encore exécuté migrate_to_s3), et cela semble fonctionner correctement ! aucun problème notable jusqu’à présent.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: "us-east-1" # alias vers auto
#DISCOURSE_S3_INSTALL_CORS_RULE: true # cela devrait être pris en charge
DISCOURSE_S3_ENDPOINT: S3_API_URL
DISCOURSE_S3_ACCESS_KEY_ID: xxx
DISCOURSE_S3_SECRET_ACCESS_KEY: xxxx
DISCOURSE_S3_CDN_URL: votre url cdn
DISCOURSE_S3_BUCKET: NOM_DU_BUCKET
y a-t-il un moyen de spécifier un hôte séparé pour les sauvegardes ? ce serait formidable si possible de laisser R2 uniquement pour les choses liées au CDN.
Il est étrange que les paramètres dans ENV ne se reflètent pas dans l’interface d’administration. Y a-t-il une substitution ? Les nouveaux paramètres de S3 dans l’interface d’administration remplaceront-ils ceux de l’environnement ?
) à peu près ici, un peu comme la façon dont les 