All plugins not functioning due to CORS error after recent upgrade

Since last week, all plugins both core and installed have stopped functioning even when enabled on our forum. Initially I thought this was something to do with the previously mentioned bug FIX: Compile missing rollup plugin bundles on demand in development - #8 but we have run multiple updates since and nothing has fixed it. I tried to enable a previously unused plugin, the preinstalled User Notes one, and there’s no options to add notes for any users. Even the docker manager has stopped so all updates have to be run on a server level, allowing only one person to apply them instead of the admin team.

I’ve tried looking around for a solution for this, but all I have come across is plugin disabled automatically or something along those lines, not really as specific as this.

Could anyone please advise any possible solutions or routes we should be looking down, as we’re rather avoid a rollback but so far it looks like it may be the last option.

Thanks as always for everyone here and your ongoing support :smiley:

2 Likes

Hmm. This looks like it’s an issue with your CDN:


I enabled my CORS ignore plugin and the scripts successfully loaded but I don’t visibly see any changes from plugins. I’d recommend trying that, and if it works you should find what’s causing the error with your CDN.

7 Likes

Thank you so much for taking the time to look into this for us. We’ll run some tests over the weekend and update when we can.

3 Likes

I’ve got the same problem with a bunnycdn. It was working fine until a recent update.

I tried adding .js to the CORS headers at bunny.net as described here:

As was the case then, I don’t understand why this problem started when I upgraded to 6800ad3adf3ef9c3caeb9a4d849997c7a3dc98d7 last week.

4 Likes

Thanks Jay, we have Bunny and the fix you mentioned has sorted all the issues out now! Thank you and everyone for the help and support on this one, our forum is back to normal. Well as normal as it can be :smiley:

1 Like

Glad to hear you got it sorted!

In the new plugin system, we use script type="module", which requires the correct CORS headers to be set. Old-style script type="text/javascript" do not require those headers.

We’ve been slowly migrating different systems to type="module" over the last few years. Themes were already using it, and so was highlightjs (which was the one in the other topic). Loading fonts from the CDN also has the CORS requirement.

So there were probably some other things subtly broken, even before the recent changes to the plugin system. Now that you’ve set the CORS config, everything should be working again :chefs_kiss:

5 Likes

Aha. That’s what I would not have guessed.

1 Like

Just a heads up for folks, if you are using Azure Classic CDN this issue has started to occur. I am trying out a fix on the CDN side, but I may need to migrate to proper front door rather than classic CDN

1 Like

Yep, confirmed this issue on Azure Classic CDN too.

You need to add a new rule to the rules engine, example below:

"rules": [

                        {

                            "name": "JSCORS",

                            "order": 1,

                            "conditions": [

                                {

                                    "name": "RequestUri",

                                    "parameters": {

                                        "typeName": "DeliveryRuleRequestUriConditionParameters",

                                        "operator": "Contains",

                                        "negateCondition": false,

                                        "matchValues": [

                                            "/assets/js/plugins/"

                                        ],

                                        "transforms": []

                                    }

                                }

                            ],

                            "actions": [

                                {

                                    "name": "ModifyResponseHeader",

                                    "parameters": {

                                        "typeName": "DeliveryRuleHeaderActionParameters",

                                        "headerAction": "Overwrite",

                                        "headerName": "Access-Control-Allow-Origin",

                                        "value": "https://forums.mycoolforum.com"

                                    }

                                },

                                {

                                    "name": "ModifyResponseHeader",

                                    "parameters": {

                                        "typeName": "DeliveryRuleHeaderActionParameters",

                                        "headerAction": "Overwrite",

                                        "headerName": "Content-Type",

                                        "value": "application/javascript"

                                    }

                                },

                                {

                                    "name": "CacheExpiration",

                                    "parameters": {

                                        "typeName": "DeliveryRuleCacheExpirationActionParameters",

                                        "cacheBehavior": "BypassCache",

                                        "cacheType": "All"

                                    }

                                }

                            ]

weirdly this issue hasn’t impacted themes, only plugins for us.

Is there somewhere to find instructions or guidance regarding these recent changes regarding CORS for those of us using Cloudflare?

@pfaffman @TomoftheFog @tanya_byrne @denvergeeks please could you confirm how your assets are configured? Do you just have a CDN + the application server? Or do you also store assets on S3/S3-compatible storage?

If you are using S3/S3-compatible storage, then unfortunately the only reliable way is to add some CDN-specific configuration. I assumed this topic was about S3 assets, but now I’m not so sure?

For people using a simple CDN against the application server, there shouldn’t have been any extra configuration work required. It should ‘just work’, exactly the same as theme-javascripts and hightlightjs bundles. But it looks like we were indeed missing the header in our default NGINX configuration. Sorry about that!

This should get things working again:

https://github.com/discourse/discourse/pull/39031

Once this is merged, a ./launcher rebuild app will be required for it to take effect. NGINX config changes are not applied during UI updates.

3 Likes

Added this information to the main topic:

Sorry for the disruption here! We should’ve done some more extensive testing with different CDN configurations. Please let us know if you’re still experiencing any issues after a rebuild.

2 Likes

Confirming we don’t use S3

1 Like

All the sites that I’m aware of exhibiting the problem are on S3. Some CDNs already had JS in the list and others didn’t. I don’t know why that might be; perhaps defaults changed over the years?

3 Likes

Sorry for the late reply, we do use S3.

2 Likes

I was having a hard time getting the CORS settings in Cloudflare R2 to work for this with a custom domain. I ended up brute forcing it by using a header transform rule to always insert the right header for my CDN domain. Just in case this helps someone else.

We’ve also found another issue since coming across this problem - some users are not able to see avatar images when using the Preformatted Text markdown button. It tries to load highlight-js and gets an error, saying CORS failed:

Not sure if this is just at our end, but wanted to make all aware in case it is related.

1 Like

I assume f.insertcred.it is your S3 CDN? HighlightJS should be loaded from the ‘application CDN’, not the S3 CDN, so this is a surprising issue. As far as I know, nothing related to highlightjs has changed over the last few months.

Do you have an app CDN? Or just S3 + S3 CDN?

2 Likes

I’ve received an update from the head admin on the forum:


As far as I’m aware we don’t have a CDN app. We haven’t uncommented the DISCOURSE_CDN_URL in app.yml.

We only use the S3 varables like DISCOURSE_S3_ENDPOINT and DISCOURSE_S3_CDN_URL, etc etc.

Here’s our app.yml with sensitive info removed

## this is the all-in-one, standalone Discourse Docker container template
##
## After making changes to this file, you MUST rebuild
## /var/discourse/launcher rebuild app
##
## BE *VERY* CAREFUL WHEN EDITING!
## YAML FILES ARE SUPER SUPER SENSITIVE TO MISTAKES IN WHITESPACE OR ALIGNMENT!
## visit http://www.yamllint.com/ to validate this file as needed

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  ## Uncomment the next line to enable the IPv6 listener
  #- "templates/web.ipv6.template.yml"
  - "templates/web.ratelimited.template.yml"
  ## Uncomment these two lines if you wish to add Lets Encrypt (https)
  - "templates/web.ssl.template.yml"
  - "templates/web.letsencrypt.ssl.template.yml"

## which TCP/IP ports should this container expose?
## If you want Discourse to share a port with another webserver like Apache or nginx,
## see https://meta.discourse.org/t/17247 for details
expose:
  - "80:80"   # http
  - "443:443" # https

params:
  db_default_text_search_config: "pg_catalog.english"

  ## Set db_shared_buffers to a max of 25% of the total memory.
  ## will be set automatically by bootstrap based on detected RAM, or you can override
  db_shared_buffers: "256MB"

  ## can improve sorting performance, but adds memory usage per-connection
  #db_work_mem: "40MB"

  ## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed

  ## Maximum upload size (default: 10m)
  upload_size: 20m

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8
  # DISCOURSE_DEFAULT_LOCALE: en

  ## How many concurrent web requests are supported? Depends on memory and CPU cores.
  ## will be set automatically by bootstrap based on detected CPUs, or you can override
  UNICORN_WORKERS: 4

  ## TODO: The domain name this Discourse instance will respond to
  ## Required. Discourse will not work with a bare IP number.
  DISCOURSE_HOSTNAME: forums.insertcredit.com

  ## Uncomment if you want the container to be started with the same
  ## hostname (-h option) as specified above (default "$hostname-$config")
  #DOCKER_USE_HOSTNAME: true

  ## TODO: List of comma delimited emails that will be made admin and developer
  ## on initial signup example 'user1@example.com,user2@example.com'
  DISCOURSE_DEVELOPER_EMAILS: 'EMAIL'
  
  ## TODO: The SMTP mail server used to validate new accounts and send notifications
  # SMTP ADDRESS, username, and password are required
  # WARNING the char '#' in SMTP password can cause problems!
  DISCOURSE_SMTP_ADDRESS: smtp.mailgun.org
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: USERNAME
  DISCOURSE_SMTP_PASSWORD: "PASSWORD"
  DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)
  DISCOURSE_SMTP_DOMAIN: forums.insertcredit.com
  DISCOURSE_NOTIFICATION_EMAIL: noreply@forum.insertcred.it
  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: nyc3
  DISCOURSE_S3_ENDPOINT: https://nyc3.digitaloceanspaces.com
  DISCOURSE_S3_ACCESS_KEY_ID: KEY_ID
  DISCOURSE_S3_SECRET_ACCESS_KEY: ACCESS_KEY_VALYE
  DISCOURSE_S3_CDN_URL: https://f.insertcred.it
  DISCOURSE_S3_BUCKET: insertcredit-forum
  DISCOURSE_S3_BACKUP_BUCKET: insertcredit-forum-backup
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false

  DISCOURSE_CAN_PERMANENTLY_DELETE: true

  ## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
  LETSENCRYPT_ACCOUNT_EMAIL: EMAIL

  ## The http or https CDN address for this Discourse instance (configured to pull)
  ## see https://meta.discourse.org/t/14857 for details
  #DISCOURSE_CDN_URL: https://discourse-cdn.example.com

  ## The maxmind geolocation IP address key for IP address lookup
  ## see https://meta.discourse.org/t/-/137387/23 for details
  #DISCOURSE_MAXMIND_LICENSE_KEY: 1234567890123456

## The Docker container is stateless; all data is stored in /shared
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-bbcode-color.git
          - git clone https://github.com/discourse/discourse-signatures.git
          - git clone https://github.com/discourse/discourse-chart.git
  after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

## Any custom commands to run after building
run:
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  #- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
  - exec: echo "End of custom commands"

I hope this is of some help regarding the ask. One point to note is that we haven’t had any reports of the issues of avatars disappearing that we did a few days ago. To my knowledge anything hasn’t been changed so we’re not sure if the issue was just a small group of users that since the previous problem was resolved, it’s then in turn sorted itself out over time.

Thanks again for looking into this.

1 Like