Avatar, Site Logos, and Cert Errors

[markcichy (Mark)]

Here’s a link to one of the instances:
https://discourse.mobiusnode.io

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/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # remove - https will be handled by outer nginx
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- Added
# which ports to expose?
# expose: comment out entire section

[itsbhanusharma (Bhanu Sharma)]

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?

[markcichy (Mark)]

Signup as user, once signed up and logged in all hell breaks loose and I get the errors noted previously.

[itsbhanusharma (Bhanu Sharma)]

Ok I’ll signup as a bogus user through firefox rn.

[itsbhanusharma (Bhanu Sharma)]

Your emails never reach my inbox. have tried resend to no avail. Are you just manually activating accounts here?

[markcichy (Mark)]

No. They likely went to Junk or Spam. No complaints from any users on that front.

[itsbhanusharma (Bhanu Sharma)]

Hell didn’t break lose here. One potential issue is that your emails still contain the http:// link
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.

[markcichy (Mark)]

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.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

it doesn’t matter what what link is shown there

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.

[markcichy (Mark)]

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.

[markcichy (Mark)]

Also, when I turn force-https on it breaks my site. And users can’t auth.

[itsbhanusharma (Bhanu Sharma)]

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.

@markcichy

Also, when I turn force-https on it breaks my site. And users can’t auth.

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.

[markcichy (Mark)]

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_pass to 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.

[itsbhanusharma (Bhanu Sharma)]

proxy_pass 192.168.20.10:8080

in discourse, expose 192.168.20.10:8080:80

remove the socketed template.

enable force_https

Profit.

[markcichy (Mark)]

This has a whole bunch of implications beyond what you’ve just written that I’ll have to investigate–we could have started there.

Immediate questions:

1. In app.yml change default listening port to 8080?
2. What about SSL 443? Leave 443?
3. Remove the redirect on 80 from Nginx server block?
4. Does #3 matter if I’m just changing the proxy_pass on the internal side? Probably not? I’m just re-routing to 8080?
5. The biggest question: why? Why would this make a difference, changing to 8080 from 80?
6. Keep all other Templates active? Just comment out socketed?

Thanks for your help, and patience.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

In app.yml change default listening port to 8080?

That’s your preference, I wrote it as an example. You can also choose to expose 80.

@markcichy

What about SSL 443? Leave 443?

There is no benefit or sense in enabling ssl on a local network

@markcichy

Remove the redirect on 80 from Nginx server block?

That has to exist.

server {
    listen 80;
    server_name discourse.example.com;
    return 301 https://example.com$request_uri;
}

@markcichy

Does #3 matter if I’m just changing the proxy_pass on the internal side? Probably not? I’m just re-routing to 8080?

That’s exactly what’s happening, You’re forwarding all requests being received by your proxy/ingress to an internal backend on port 8080 (i.e. discourse)

@markcichy

The biggest question: why? Why would this make a difference, changing to 8080 from 80?

Answered in #1 it was a personal preference, feel free to use whichever port you fancy.

@markcichy

Keep all other Templates active? Just comment out socketed ?

You particularly don’t need anything that has to do with sockets or ssl on the internal server. SSL should be properly terminated on the reverse-proxy.

NB: most of it is a personal preference based on deployment for customers.

[markcichy (Mark)]

Okay. Thanks for comments.

Here is my Nginx server block, FYI:

server {
# ssl
listen 443 ssl http2;
listen [::]:443 ssl http2;

   server_name discourse.mobiusnode.io;

   location / {
           #http trafic
           proxy_pass http://192.168.86.108;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header Host $http_host;
           proxy_http_version 1.1;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto https;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection "upgrade";

   }

ssl on;
ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # managed by Certbot
ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # managed by Certbot

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

add_header Strict-Transport-Security "max-age=63072000;";
ssl_stapling on;
ssl_stapling_verify on;

client_max_body_size 0;

}

server {
if ($host = discourse.mobiusnode.io) {
return 301 https://$host$request_uri;
} # managed by Certbot

listen 80;
listen [::]:80;

server_name discourse.mobiusnode.io;
return 404; # managed by Certbot

}

[markcichy (Mark)]

The behaviour I am experience is under those conditions above.

Beginning of app.yml looks like this:

## 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"

## 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: "1024MB"

## 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

[RGJ (Richard - Communiteq)]

You are connecting to port 80 on the second nginx, so it thinks you’re connecting to http and not https.

Try to find the X-Forwarded-Proto in the inner nginx and change proxy_set_header X-Forwarded-Proto $thescheme; to proxy_set_header X-Forwarded-Proto https;

or forward your traffic to https proxy_pass https://192.168.86.108

[itsbhanusharma (Bhanu Sharma)]

@markcichy

- "80:80" # http
- "443:443" # https

This part needs to be changed