Totally blank upgrades page
The discussion revolves around an issue where the upgrades page is completely blank. paulrudy initially reports the problem and shares the HTML code for the page, which is empty.
sam suggests removing third-party plugins and trying safe mode. paulrudy tries these options but the issue persists. sam then asks for a sanitized version of the app.yml file, which paulrudy provides.
sam recommends rebuilding the Discourse instance without third-party plugins. paulrudy tries this, but the issue remains. sam then suggests checking the Chrome Dev Tools console for errors, which reveals a Content Security Policy (CSP) issue with a script from a CDN.
Don recommends adding the CDN URL to the CSP whitelist, which resolves the issue. pmusaraj explains that the issue was caused by a bug in the docker_manager plugin, which has since been fixed. paulrudy confirms that updating the plugin resolves the issue without needing to manually add the CDN URL to the CSP whitelist.
My upgrades page is completely blank.
I did ./launcher rebuild app and managed to upgrade to v2.6.0beta4, but even afterward, the upgrades page is blank. The <body> tag for the page is:
<body class="highlighter-context">
</body>
Any suggestions?
Can you share a link to your site?
It’s a closed forum. Happy to share but I figure that makes a difference, yeah?
I recommend you remove all third party plugins and rebuild. Also try safe mode see:
Thanks. I got some time to try these. Various options in safe mode didn’t help. Disabling all third-party plugins and including only docker_manager also didn’t change anything. Still a blank white screen.
I saw a post with the same issue from earlier this year, but the OP stopped responding, so no obvious cause or resolution.
I recommend posting a sanitized version of your app.yml … it will help us figure out what is wrong.
Okay, here you go:
## 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"
- "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"
- "templates/web.socketed.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: "128MB"
## 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
env:
LANG: 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: 2
## TODO: The domain name this Discourse instance will respond to
## Required. Discourse will not work with a bare IP number.
DISCOURSE_HOSTNAME: <REMOVED FOR PUBLIC POSTING>
## 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: <REMOVED FOR PUBLIC POSTING>
## 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: <REMOVED FOR PUBLIC POSTING>
DISCOURSE_SMTP_PASSWORD: <REMOVED FOR PUBLIC POSTING>
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default true)
## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
LETSENCRYPT_ACCOUNT_EMAIL: <REMOVED FOR PUBLIC POSTING>
## 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
# S3 Setup
DISCOURSE_CDN_URL: <REMOVED FOR PUBLIC POSTING>
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: "us-west-002"
DISCOURSE_S3_ENDPOINT: https://s3.us-west-002.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: <REMOVED FOR PUBLIC POSTING>
DISCOURSE_S3_SECRET_ACCESS_KEY: <REMOVED FOR PUBLIC POSTING>
DISCOURSE_S3_CDN_URL: <REMOVED FOR PUBLIC POSTING>
DISCOURSE_S3_BUCKET: <REMOVED FOR PUBLIC POSTING>
DISCOURSE_S3_BACKUP_BUCKET: <REMOVED FOR PUBLIC POSTING>
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_INSTALL_CORS_RULE: false
## 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-user-notes
- git clone https://github.com/discourse/discourse-assign
- git clone https://github.com/discourse/discourse-policy
- git clone https://github.com/discourse/discourse-tooltips
- git clone https://github.com/discourse/discourse-saved-searches
- git clone https://github.com/discourse/discourse-knowledge-explorer
- git clone https://github.com/discourse/discourse-voting
- git clone https://github.com/discourse/discourse-translator
- git clone https://github.com/angusmcleod/discourse-elections
- git clone https://github.com/discourse/discourse-styleguide
- git clone https://github.com/Ahmedgagan/discourse-custom-trust-level
- git clone https://github.com/paviliondev/discourse-quick-messages
- git clone https://github.com/paviliondev/discourse-locations
- git clone https://github.com/discourse/discourse-calendar
# Object storage
after_assets_precompile:
- exec:
cd: $home
cmd:
- su discourse -c 'bundle exec rake s3:upload_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"
ok… step one I recommend here is rebuilding this thing without any third party plugins. Only keep ones that are /discourse/discourse
Then if that works you can bisect to find out which plugin is causing the trouble.
Well, docker_manage plugin is not a discourse/discourse path, but with it disabled, ...admin/upgrade page doesn’t exist.
Enabling only the docker_manage plugin results in the same blank upgrades page.
Sorry, you’re right, I must have been hallucinating. Scratch that, it is in the discourse/ path.
But anyway, still a blank white screen.
With the availability of 2.6.0.beta5 (I’m on 2.6.0.beta4), I’m still running into a blank upgrades page. I’d be grateful for any further advice, since I’ve tried disabling plugins to no avail.
Have a look at chrome dev tools, are there any errors in the console when the page is white? My guess is that this is something to do with your CSP.
Thank you, you’re right—it’s refusing to load a script coming through my CDN. With url’s sanitized:
upgrade:1 Refused to load the script 'https://cdn-to-discourse.b-cdn.net/assets/docker-manager-app-32418f2f7cd50e6f4a0b8d13badc4e59f6a1ad74e7bed270f3a051478fed773d.js' because it violates the following Content Security Policy directive: "script-src https://forum.example.com/logs/ https://forum.example.com/sidekiq/ https://forum.example.com/mini-profiler-resources/ https://cdn-to-s3.b-cdn.net/assets/ https://cdn-to-s3.b-cdn.net/brotli_asset/ https://forum.example.com/extra-locales/ https://cdn-to-discourse.b-cdn.net/highlight-js/ https://cdn-to-discourse.b-cdn.net/javascripts/ https://cdn-to-discourse.b-cdn.net/plugins/ https://cdn-to-discourse.b-cdn.net/theme-javascripts/ https://cdn-to-discourse.b-cdn.net/svg-sprite/ https://matomo.example.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
The Security settings page says “The current host and CDN are included by default.” Should I manually add the CDN to the whitelist anyway?
I see that an identical issue was brought up here, without a final answer about why the default whitelisting wasn’t working.
Hello,
I think you should add this url to admin CSP setting (content security policy script src):
https://cdn-to-discourse.b-cdn.net/assets/
And after check again the chrome dev tools errors.
Yes that works. I’m curious why the default whitelisting is not doing this automatically, though.
I am curious as well, how is your CDN configured? We may be missing some magic from docker-manager plugin.
cc @pmusaraj
Yes, indeed, we were. The docker_manager plugin was loading two JS files in a template using javascript_include_tag, which isn’t aware of DISCOURSE_S3_CDN_URL so it was defaulting to DISCOURSE_CDN_URL and tripping up the CSP.
Should be fixed now via FIX: blank upgrade page when using S3 CDN and CSP · discourse/docker_manager@3d37fd6 · GitHub
@paulrudy if you update the docker_manager plugin, you should no longer need to manually add https://cdn-to-discourse.b-cdn.net/assets/ to your CSP.
