Comportement étrange avec Digital Ocean Spaces/S3 et de nombreuses règles CORS dupliquées pour `example.com`

J’ai obtenu cette erreur lors d’un récent bootstrap. J’utilise Digital Ocean dans SFO3.

"Tasks: TOP => s3:upload_assets => s3:ensure_cors_rules", "(See full trace by running
 task with --trace)", "I, [2021-12-16T21:19:05.748497 #1]  INFO -- : Installing CORS rules...", "Attempting to apply ASSETS S3 CORS ruleset in bucket pfaffmanager.", "At
tempting to apply BACKUP_DIRECT_UPLOAD S3 CORS ruleset in bucket pfaffmanager."]

Y a-t-il quelque chose qui pourrait expliquer cela et qui aurait une solution ?

Hmm. J’ai regardé les paramètres et il y avait un tas de règles CORS apparemment identiques. J’en ai supprimé une et cela les a toutes supprimées. Il s’agit d’un serveur de staging sur lequel j’ai effectué un million (ou peut-être une centaine, peu importe ?) de mises à niveau, donc cela pourrait éventuellement arriver à tout le monde utilisant Digital Ocean, mais pour la plupart des gens, cela prendrait plutôt 10 ans que 8 mois.

Après avoir supprimé les règles CORS, le bootstrap suivant a réussi et il y avait alors 2 règles CORS dans les paramètres du bucket des espaces. Mais regardez, il semble que les règles soient définies pour example.com. :man_shrugging:

Un autre bucket dans AMS3 que je suis sûr d’avoir bootstrappé un bon nombre de fois a 3 règles comme celle ci-dessus. Toutes pour example.com. J’ai vérifié app.yml pour voir si je faisais quelque chose de stupide (et si c’était le cas, cela aurait du sens que je l’aie fait de la même manière à plusieurs endroits), mais il n’y a pas de example.com dans le yml.

Lors de la reconstruction, je vois ceci dans les logs :


I, [2021-12-16T21:46:58.038151 #1]  INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
I, [2021-12-16T21:47:39.039145 #1]  INFO -- : Installing CORS rules...
Attempting to apply ASSETS S3 CORS ruleset in bucket pfaffmanager.
Attempting to apply BACKUP_DIRECT_UPLOAD S3 CORS ruleset in bucket pfaffmanager.
Assets rules status: rules_applied.
Backup rules status: rules_applied.
Direct upload rules status: rules_skipped_from_settings.

J’ai regardé dans le code à des endroits comme s3_backup_store.rb pour example.com et je n’arrive pas à trouver une explication.

3 « J'aime »

Il semble que nous devrions recommander DISCOURSE_S3_INSTALL_CORS_RULE: false pour DO comme nous le faisons déjà pour GCP et BackBlaze dans Utilisation du stockage d’objets pour les téléchargements (S3 et clones) :thinking:

4 « J'aime »

Bonjour,

Désolé de déterrer ce sujet, mais je pense avoir eu un problème similaire il y a quelques jours.

Ma configuration :

Digital Ocean Spaces avec s3:upload_assets et s3:expire_missing_assets.
CDN - Bunny

Il semble que chaque reconstruction ou mise à jour d’administration, lorsqu’elle télécharge des actifs, génère une nouvelle règle CORS. Elle duplique en fait la règle d’origine. Malheureusement, je n’ai pas copié le message d’erreur de la console, mais c’était quelque chose avant le téléchargement des actifs - j’ai atteint le nombre maximum de 100 règles CORS. Je suis donc allé sur Digital Ocean et j’ai vérifié les règles et oui, il y en avait 100. :smiley: J’ai donc fait la même chose que @pfaffman, j’en ai supprimé une et cela a supprimé toutes les règles. Après cela, les actifs ont été téléchargés avec succès lors de la reconstruction.

Lorsque j’ai configuré cela, j’ai suivi les instructions ici : Configure an S3 compatible object storage provider for uploads qui ne contient pas encore cette ligne.

L’ajout de cette ligne empêchera-t-il la génération de règles CORS dupliquées ? Merci :slightly_smiling_face:

J’ai mis à jour l’autre sujet, donc j’espère que cela n’arrivera plus aux utilisateurs à l’avenir ! Merci de l’avoir signalé.

2 « J'aime »