Site logos and https with proxy

Hello,

on 2 different discourse instances
both upgraded to v2.3.0.beta5 +43

the different logo that were previously uploaded in Settings/Required
https://{FQDN}/admin/site_settings/category/required

are now being served with http:// instead of https://
which now create “Mixed Content” warnings (it was working fine before that)

eg.
before

<div class="logo-wrapper">
<a href="/">
    <img src="https://{FQDN}/uploads/default/original/2X/5/5f85dfe8d0408c92c505a3a43699735abee9a972.png" alt="foobar community" id="site-logo">
</a>
</div>

after

<div class="logo-wrapper">
<a href="/">
    <img src="http://{FQDN}/uploads/default/original/2X/5/5f85dfe8d0408c92c505a3a43699735abee9a972.png" alt="foobar community" id="site-logo">
</a>
</div>

if you preview the logo in the admin page the image location is with https://

https://{FQDN}/uploads/default/original/2X/5/5f85dfe8d0408c92c505a3a43699735abee9a972.png

if you reset the logo, same behaviour

if the image location indicates

https://{FQDN}/images/d-logo-sketch.png

the HTML page use http://

<div class="logo-wrapper">
<a href="/">
    <img src="http://{FQDN}/images/d-logo-sketch.png" alt="foobar community" id="site-logo">
</a>
</div>

our special case is we host everything with an apache 2 front-end, same for the SSL certs, and use proxying to the discourse instance

here a sample config

<Proxy balancer://unicorns>
    BalancerMember http://127.0.0.1:4000
</Proxy>

<VirtualHost *:443>
    ServerAdmin ${APACHE_SERVER_ADMIN}
    ServerName discuss.foobar.com
    ServerSignature Off

    DocumentRoot /home/vhosts/foobar.com/discuss/htdocs
    UserDir disabled
    DirectoryIndex disabled

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    ErrorLog ${APACHE_LOG_DIR}/foobar.discuss-error.log
    CustomLog ${APACHE_LOG_DIR}/foobar.discuss-access.log vhost_combined

    SSLEngine on
    SSLCertificateFile      /etc/letsencrypt/live/discuss.foobar.com/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/discuss.foobar.com/chain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/discuss.foobar.com/privkey.pem

    # Optional
    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=15768000"

    ErrorDocument 404 /404.html
    ErrorDocument 500 /500.html
    ErrorDocument 503 /maintenance.html

    <Directory />
            Options FollowSymLinks
            AllowOverride All
    </Directory>

    <Directory "/home/vhosts/foobar.com/discuss/htdocs/">
            Options -MultiViews
            AllowOverride All
            Require all granted
    </Directory>

    RewriteEngine on

    RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
    RewriteCond %{DOCUMENT_ROOT}/maintenance.enable -f
    RewriteCond %{SCRIPT_FILENAME} !maintenance.html
    RewriteCond %{REQUEST_URI} !\.(jpe?g?|png|gif|css|js) [NC]
    RewriteRule ^.*$ /maintenance.html [R=503,L]

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteRule ^/(.*)$ balancer://unicorns%{REQUEST_URI} [P,QSA,L]

</VirtualHost>

so I guess the discourse instance does not know it has SSL cert enabled

now you can fix it by using “force https”

but some URL within the page are still using http://


    <link rel="alternate" type="application/rss+xml" title="Latest posts" href="https://{FQDN}/posts.rss" />
    <link rel="alternate" type="application/rss+xml" title="Latest topics" href="http://{FQDN}/latest.rss" />

I can not pinpoint exactly where this regression occurred, but it was working before

showing some kind of warning in the admin would be nice as it was not obvious what was causing this behaviour

1 Like

Running https without “force https” set isn’t supported – and never has been.

2 Likes

ok, so I understand “not a valid bug” because “never was supported”
I understand 5/5 what you’re saying here, all good with me