Avatar, Site Logos, and Cert Errors

[markcichy (Mark)]

Hello!

I’ve setup Discourse servers in a about 5 instances now and all seem to be exhibiting odd behaviour; not sure if it is indeed a Bug or if anyone else has experience same.

Steps to Recreate

• Server setup goes smooth
• Wizard walk through is fine, all images are uploaded and shown as expected
• User receives signup link, clicks to follow, and registration all goes well
• (Here’s where things go sideways) User logs in and site logos are all broken – only showing text titles
• User cannot upload/assign custom Avatar
• Site certificate complains that site is not secure
• For some reason this ONLY affects the browser used to sign-up, and has a much higher failure rate in Chrome

Troubleshooting

• We’ve tried telling users to flush browser cache and cookies – still broken
• We’ve asked users to reinstall browsers, mostly Chrome – still broken
• We’ve asked people to use an alternative identity in Chrome or try a different browser (Safari, Firefox, etc.) – works!

We have absolutely no idea why the last item works and why the originating signup identity is messed up. It would not be tenable to ask allow our users (about 6-700) to sign out of their Chrome identity and sign back in – if, for some reason that is indeed the solution.

Any ideas?

Cheers,
Mark

[itsbhanusharma (Bhanu Sharma)]

Is it a standard 30 mins installation? Or anything custom here?

Did you enable force_https in the site settings to see if that fixes the issue?

I can’t repro your steps in my sandbox on latest branch so it’ll be really helpful if you could share link to one of the affected instances.

[markcichy (Mark)]

Hi Bahnu–

• Standard 30 min install
• Nothing custom
• Have not enabled force_https but as I said, this issue only affects the browser used to register

[itsbhanusharma (Bhanu Sharma)]

Try enabling force_https I’m 99% sure that it’ll solve this for you.

[markcichy (Mark)]

Okay. All install instances receive their cert from a reverse Nginx proxy that IS NOT the same machine. Will force_https still make a difference?

[itsbhanusharma (Bhanu Sharma)]

So that’s not a standard install. You said it was one.

If discourse is behind a Properly Configured reverse proxy, force_https will definitely make a difference. The setting essentially tells discourse to load all resources and assets over HTTPS

[markcichy (Mark)]

Alright, my apologies.

So, are we talking about force_https under app.yml or my Nginx server block?

I’m already passing though traffic properly–but I don’t see the property in the yml file.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

So, are we talking about force_https under app.yml or my Nginx server block?

Neither.

force_https is a site setting that you need to enable in admin area.

[markcichy (Mark)]

Will it potentially lock me out?

[itsbhanusharma (Bhanu Sharma)]

Unless your reverse proxy is configured incorrectly, there is absolutely nothing to worry about here.

If you’re not sure about the reverse proxy configuration, take a look at this config and match it to yours

Adding an offline page when rebuilding

This guide is intended for advanced users, who are already using nginx outside the docker container. By following this guide you make your setup more complicated and will loose some speed benefits like HTTP2 if you’re not running Ubuntu 16.04 or later. Proceed with caution! When Discourse is rebuilding or starting up, your users will usually either see an error message from their browser… [image] …or a not-so-nice 502 error message from Nginx: [image] If you’re a perfectionist l…

[markcichy (Mark)]

It did, btw. Lock me out. Enabling force_https fixed the image issue BUT made it impossible to authenticate from browsers with a new session. Existing session fine, but the second you log out you cannot get back in.

[itsbhanusharma (Bhanu Sharma)]

That’s something wrong with your reverse proxy. You’ll have to check it’s configuration to ensure that everything is set up correctly.

[markcichy (Mark)]

Just did, I have already effectively set everything up in my server block the way that article suggests. Which is probably why sessions in alt profiles/browsers work normally after initial signup/auth.

The only element where my config differs is that I am not using templates.yml.

This is going to take A LOT more investigation.

[markcichy (Mark)]

Okay. Odd. I have not changed a thing. All images work totally fine. Period.

Still getting invalid cert on initial install browser/usr ONLY though.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

Still getting invalid cert on initial install browser/usr ONLY though.

That could be browser cache or misconfigured certificate. Did you get a letsencrypt ssl or some other one?

[markcichy (Mark)]

It’s LetsEncrypt via Certbot. Cert is good. I think it is browser cache.

[itsbhanusharma (Bhanu Sharma)]

Try registering in incognito. do you still get an error?

And one thing I’m assuming is fishy here. Are you using some kind of external authentication? ( social login / SSO etc. )

[markcichy (Mark)]

No. No external auth. Tried Incognito. No dice. Same result.
Must be something in server block. Will investigate a bit later.

[itsbhanusharma (Bhanu Sharma)]

mind sharing link to one such install?

[riking (Kane York)]

Did you base your nginx config off the one listed here?

Running other websites on the same machine as Discourse

If you want to run other websites on the same machine as Discourse, you need to set up an extra NGINX or HAProxy proxy in front of the Docker container. NOTE: This is for advanced admins This guide assumes you already have Discourse working - if you don’t, it may be hard to tell whether or not the configuration is working. You cannot use ./discourse-setup to set up Discourse if another server is using port 80 or 443. You will need to copy and edit samples/standalone.yml with your favorite tex…

Make sure that you’re sending X-Forwarded-Proto.