Hi, Today I attempted to update via ssh from v2.2.0beta2 +5 → 2.2.0beta4. I used the following command which I have used for the past ~2 years without trouble: cd / var / discourse git pull ./launcher rebuild app After the update my site has a blank page, and these errors are visible in the console view: [discourse_errorsOnUpdate-20181110] A couple weeks back I attempted to update to the version previous to 2.2.0beta4 (2.2.0beta3 ?) and the same thing happened so I thought I would wait to see if the next one helped fix this. Suggestions on correcting this would be appreciated, thanks in advance.

If it comes to that the marketplace is the place to take it. As I said above, Discourse only needs one rule at cloudflare. That rule is: [cloudflare] You don’t want anything interfering with the javascript or how the page is loaded, which minification and rocket loader will do. Both usually end up with the issue you’re reporting. If you want to cache assets then only turn that on after proving the site works with the above, and even then only use standard caching with /uploads/* - caching other stuff isn’t supported. Knowing the FQDN helps us use other tools to look, but as we don’t have it we will skip that stage entirely. That should be the only rule touching your site. If you have any others which risk overlapping then for now just shut them off. If that doesn’t work then it’s time to look at apps. Because your upgrade triggered the problem though it’s also still possible this is due to an old plugin. You said your install is bone stock, but do you mean just in terms of customisations? Are there any plugins added to the app.yml beyond the defaults? Broken plugins are also going to rear their heads during an upgrade.

No it won’t. Test using safe mode /safe-mode and if that works visit /admin to disable any customisations. Just create a new theme with no changes and temporarily set it to default. If safe mode works and disabling customisations doesn’t restore your front page you need to start disabling plugins to pinpoint the cause. Are you using Cloudflare?

Ok, I don’t currently use any customizations, it’s bone stock. I will certainly still try this though and see what happens. I do use cloudflare and I set the caching to dev mode ( no caching ) and also purged all cached data to see if that would help. It did not. Any other suggestions are appeciated, I will let you know what the results are when I try testing using safe mode later. I’m currently AFK and it takes a bit of time.

Turn off the orange cloud. Hard to give more advice than that as you didn’t provide a URL for us to look at directly.

Well, turning off the orange cloud defeats the purpose of using Cloudflare and significantly elevates risk. I’ll test though using a burner domain or something, thank you for the suggestion. I would not recommend people doing this as it will reveal your servers IP to crawlers immediately and the damage will be done once logged. Even if you turn orange cloud back on afterwards and have not cycled your IP, Cloudflare will no longer protect your server as the IP will be known. It wouldn’t help to give the URL at the moment because I reverted back to a good snapshot, as users are using the site at the moment. I’ll need to do maintenance in the early hours of the morning. Thank you again, I will report back later. If anyone has suggestions related to those errors shown, I will gladly test other things as well. :grinning:

For now it’s a diagnostic step. It doesn’t significantly elevate risk unless you’ve increased the attack surface of your server and done some very silly things. There are no nefarious ‘crawlers’ out to get you, the period of time this would be done for is minimal. Your server isn’t protected by Cloudflare, it actually does nothing to protect the server itself, it only proxies the FQDN, the server IP is still as vulnerable with or without it turned on. The kinds of attack you should be worried about are bots scanning entire subnets of machines, which priorities the ranges allocated to VPS services.

That’s an exaggeration, Discourse only needs one rule to work with cloudflare, there are plenty of servers which use it with Discourse. It’s always stuff added beyond that, such as apps and other rules which cause the problems. This week alone we’ve had a number of good examples. Either way, Cloudflare doesn’t do anything to harden a server beyond masquerade the FQDN. Servers which which use it are easily identifiable. Assuming it affords some additional level of protection beyond the proxy demonstrates why it can lull people into a false sense of security and actually make you more vulnerable, instead of less. [image] pfaffman: last I knew cloudflare didn’t use it on their one forum They do: > Host: community.cloudflare.com > User-Agent: curl/7.54.0 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 200 < date: Sat, 10 Nov 2018 20:41:18 GMT < content-type: text/html; charset=utf-8 < set-cookie: __cfduid=d488d0604e545aba59340201845ebb2491541882478; expires=Sun, 10-Nov-19 20:41:18 GMT; path=/; domain=.cloudflare.com; HttpOnly < vary: Accept-Encoding < x-frame-options: SAMEORIGIN < x-xss-protection: 1; mode=block < x-content-type-options: nosniff < x-download-options: noopen < x-permitted-cross-domain-policies: none < referrer-policy: strict-origin-when-cross-origin < x-discourse-route: list/latest < cache-control: no-cache, no-store < x-request-id: 7218028b-d2a8-47d7-87b7-3ea8887d2d90 < x-runtime: 0.180168 < x-discourse-trackview: 1 < discourse-proxy-id: app-router-tiehunter01 < strict-transport-security: max-age=15780000; includeSubDomains < expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" < server: cloudflare < cf-ray: 477b56d26fff5372-LAX

[image] Stephen: For now it’s a diagnostic step. It doesn’t significantly elevate risk unless you’ve increased the attack surface of your server and done some very silly things. There are no nefarious ‘crawlers’ out to get you, the period of time this would be done for is minimal. Your server isn’t protected by Cloudflare, it actually does nothing to protect the server itself, it only proxies the FQDN, the server IP is still as vulnerable with or without it turned on. The kinds of attack you should be worried about are bots scanning entire subnets of machines, which priorities the ranges allocated to VPS services. I respectfully disagree with you. There are in fact crawlers whose job is to continuously crawl domains, resolve the IP and log the DNS info. In fact, it’s a huge market. If you use Cloudflare properly, no one should ever know your servers true IP. Hence, it’s security through obscurity. I could give you a domain which has properly used Cloudflare and even the class B subnet the server is on and I doubt you will be able to correlate the two, unless of course, you slip and create an A record which has the servers true IP in it, which will get logged very quickly. Use discourse itself as an example, how do you think this passive DNS is available? https://viewdns.info/iphistory/?domain=discourse.org I digress, the intent of this topic is derailing. If you would like to discuss passive DNS, crawlers and opsec. I will be happy to do so in another category/thread.

That’s 19 addresses over 9 years for the front end site, and even viewdns admits that they don’t track subdomains. I don’t think you’re making the point you think you are. Either way, it looks like you’re on your own fixing this. Good luck!

[image] Stephen: That’s 19 addresses over 9 years for the front end site, and even viewdns admits that they don’t track subdomains. I don’t think you’re making the point you think you are. Either way, it looks like you’re on your own fixing this. Good luck! Ok, well, thank you for the suggestions. I’m sorry I cannot budge in my opinion of the DNS handling. [image] Stephen: That’s an exaggeration, Discourse only needs one rule to work with cloudflare, there are plenty of servers which use it with Discourse. It’s always stuff added beyond that, such as apps and other rules which cause the problems. This week alone we’ve had a number of good examples. Your statement here has me believe it should not be an issue anyways. I’ll keep trying, thanks. If anyone else has any suggestions related to discourse and the error I received. I welcome those.

Blank page / Error after updating due to cloudflare settings

Product Support

Matt_Campbell (Matt Campbell) November 10, 2018, 7:00pm 2

Can you please use your browser’s “view source” command to get the HTML source of the home page and provide it here? That will help us pinpoint anything unusual about your setup. Thanks.

Topic		Replies	Views
After updating website wont come back online Product Support	9	1133	October 5, 2019
Site broken due to CloudFlare Rocket Loader Product Support	14	1832	September 19, 2018
Latest update requires cache purge in CloudFlare Self-hosting	70	7178	December 5, 2017
Lots of HTTP 502 and 429 after updating to 3.4.0.beta1-dev Self-hosting	23	842	August 13, 2024
Update from 2.4.0.beta9 to 2.4.0.beta10 yields page with no content - Cloudflare Rocket Loader Self-hosting	11	2071	January 29, 2020

Blank page / Error after updating due to cloudflare settings

Related topics