That could be browser cache or misconfigured certificate. Did you get a letsencrypt ssl or some other one?
It’s LetsEncrypt via Certbot. Cert is good. I think it is browser cache.
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. )
No. No external auth. Tried Incognito. No dice. Same result.
Must be something in server block. Will investigate a bit later.
mind sharing link to one such install?
Did you base your nginx config off the one listed here?
Make sure that you’re sending
Here’s a link to one of the instances:
It is off.
X-Forwarded-Proto is in my server block. So, the only element(s) I am not employing – based on the links that you have all shared – is this:
# base templates used; can cut down to include less functionality per container templates:
# - "templates/cron.template.yml" # cron is now included in base image
# - "templates/web.ssl.template.yml" # remove - https will be handled by outer nginx
- "templates/web.socketed.template.yml" # <-- Added
# which ports to expose?
# expose: comment out entire section
I loaded the site in 3 browsers (edge, firefox and chrome mobile) I get perfectly legit cert as anon. What are your steps to repro this?
Signup as user, once signed up and logged in all hell breaks loose and I get the errors noted previously.
Ok I’ll signup as a bogus user through firefox rn.
Your emails never reach my inbox. have tried resend to no avail. Are you just manually activating accounts here?
No. They likely went to Junk or Spam. No complaints from any users on that front.
Hell didn’t break lose here. One potential issue is that your emails still contain the
However, I was properly redirected to https site for activating my account and I don’t see any SSL related errors here.
So Yeah, I’m 99% sure your
force_https is not enabled or something is very very wrong with your install that is causing this.
I have a redirect in my server block, so it doesn’t matter what what link is shown there. It will always reroute to https.
That’s where You’re wrong. If force https is enabled, discourse must send out all links as https. every single link related to the forum must be loaded over https. if you’re still doing weird things and not doing it the suggested way, you’re on your own. We can’t help past the standard procedures that work.
That doesn’t make much sense to me. If we logically break this down I am essentially doing exactly what
force-https is meant to do but with the server block.
Also, when I turn
force-https on it breaks my site. And users can’t auth.
force_https isn’t merely a rewrite. it does more than that internally. If you want your issues resolved, A solution has been already provided. If you reject the solution, feel free to take matter in your own hands and explore new avenues.
that’s because of your flaky reverse proxy. You’ll have to figure out what is wrong and do things the proper way. We can’t provide assistance with your own solutions.
All of the “solutions” that have been presented do not fit my specific use case:
- Remote server (within the same network) – I believe all the examples assume Nginx is running on the same server as Discourse, I am using
proxy_passto hit another internal IP
Why have I done this? Higher security and dispersal of resources. It’s the same reason I split up services in two ways: by container and VM. The suggested docs seem to favour a condition where all services are running on the same server.
I would imagine that the conditions described above would be fairly common. If any of those can be used to accommodate a
proxy_pass condition I am more than happy to augment my settings to suit. I just feel that providing a blanket “you’re on your own statement” because I am trying to avoid a ‘putting all my eggs in one basket’ scenario is a little unwarranted.
in discourse, expose 192.168.20.10:8080:80
remove the socketed template.