Leere Seite / Fehler nach Update aufgrund von Cloudflare-Einstellungen

[e9e61d50 (Joe)]

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:

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.

[Matt_Campbell]

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.

[Stephen]

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?

[e9e61d50 (Joe)]

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.

[Stephen]

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.

[e9e61d50 (Joe)]

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.

[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.

[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.

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.

@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

[e9e61d50 (Joe)]

@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.

[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!

[e9e61d50 (Joe)]

@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.

@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.

[Stephen]

Discourse works with Cloudflare, it’s almost certainly something you’ve done to yourself, as to what we can’t say without more information that you’re either unwilling or unable to provide.

We’re not really ones for tech support whilst blindfold and at least one arm tied behind our back(s). At least not for free.

[e9e61d50 (Joe)]

What other information could help? are there any .yml files I should be checking or configuration settings which would have caused that error?

I’ll certainly provide more details, I just need to know which ones.

Also, I’m totally willing to pay for someones expertise in solving outstanding issues.

[Stephen]

Wenn es soweit kommt, ist der Marketplace der richtige Ort, um es anzugehen.

Wie oben erwähnt, benötigt Discourse nur eine Regel bei Cloudflare. Diese Regel lautet:

Sie möchten nichts, das mit JavaScript oder dem Laden der Seite interferiert, was durch Minifizierung und Rocket Loader geschehen kann. Beides führt in der Regel zu dem von Ihnen gemeldeten Problem.

Wenn Sie Assets cachen möchten, aktivieren Sie dies erst, nachdem Sie überprüft haben, dass die Site mit der oben genannten Regel funktioniert. Verwenden Sie auch dann nur das Standard-Caching für /uploads/* – das Caching anderer Inhalte wird nicht unterstützt.

Die Kenntnis der FQDN hilft uns, andere Tools zur Untersuchung einzusetzen, aber da wir diese nicht haben, überspringen wir diesen Schritt vollständig.

Dies sollte die einzige Regel sein, die Ihre Site betrifft. Falls Sie weitere Regeln haben, die sich überschneiden könnten, schalten Sie diese vorerst einfach ab.

Sollte dies nicht funktionieren, ist es Zeit, sich die Apps anzusehen.

Da Ihr Upgrade das Problem ausgelöst hat, ist es jedoch auch möglich, dass es auf einem veralteten Plugin beruht. Sie haben erwähnt, dass Ihre Installation „bone stock" ist, meinen Sie damit nur in Bezug auf Anpassungen? Gibt es Plugins in der app.yml hinzugefügt, die über die Standardkonfiguration hinausgehen? Defekte Plugins werden sich auch während eines Upgrades bemerkbar machen.

[pfaffman (Jay Pfaffman)]

Yeah. You’re right. My vitriol is over the top. Soon, I think, there will be a howto that should make it easier for people to figure this out.

[Stephen]

There will, it’s written mostly.

Just need to grab a couple of screenshots and clarify some of the overlooked disadvantages with a couple of quick tests.

[e9e61d50 (Joe)]

So, I had a few minutes to test.

I thought this page rule was already set but it was not. So I added this page rule for the domain and it seems to be working again . Also, it had worked fine up until two updates ago, .

Great suggestion and thank you for your time. I’ll continue to test and monitor.