Images now seem to be hard-coded to HTTP or HTTPS - causes mix content issues

[raspberrycoulis]

Issue Summary

My Ghost installation is on Raspbian and works just fine (appreciate it's an unsupported stack, but I run https://ghostpi.pro where I have had no issues for many years).

I have a NAS at home, so I need to open port 443 in my router for the NAS' IP address so I can access packages installed there. Port 80 is open for my Raspberry Pi where Ghost is hosted.

To use SSL, I employ Cloudflare. This means that when I installed my Ghost blogs initially, I set them up without SSL (as to do so in the Ghost CLI would require port 443 open on my Pi's internal IP as well as port 80, which wouldn't work with my setup at home), and then redirected to HTTPS using Cloudflare's traffic rules. All this sounds complicated, but worked fine - giving me the padlock in browsers on both blogs hosted on my Pi.

However, in recent versions of Ghost (cannot remember which version exactly, but I'm running the latest version (2.19.3)) I have noticed that I no longer see the padlock in Chrome. Checking on whynopadlock.com shows that it's because my blogs are serving mixed content - mainly images - that appear to have hard-coded links on my blog (i.e. in Chrome's Inspector, an image would show as http://ghostpi.pro/content/images/2019/03/ghost2point0-install-opt.png) as opposed to relative links (i.e. /content/images/2019/03/ghost2point0-install-opt.png), which would allow for either HTTP or HTTPS depending on how the site is accessed.

I've tried to fix this by re-uploading my images (whilst accessing the blog over HTTPS) but this does not do anything and seemingly reverts back to HTTP, which causes the mixed content issue.

To Reproduce

1. Access blog over HTTPS and access the Ghost admin panel
2. Upload image
3. Save
4. Visit site
5. Image is served over HTTP causing mixed content issue.

It would make more sense to display images based on relative URLs as opposed to hard-coded HTTP links, as this is causing issues with my blog.

Technical details:

• Ghost Version: 2.19.3
• Node Version: 8.15.1
• Browser/OS: Chrome (via Windows 10) but installed on Raspbian Stretch
• Database: MySQL

[kevinansfield]

@raspberrycoulis the underlying issue is that your url config is incorrect, it should be set to https://ghostpi.com if you are serving content over https. See https://docs.ghost.org/faq/change-configured-site-url/ for details on how to change it.

I'm going to close this as a duplicate of #10417 and #10578. We're tracking the overall handling of relative/absolute URLs across the database and API output in #10477.

[raspberrycoulis]

@kevinansfield but won't updating the URL mean SSL will need to be set up via the Ghost-CLI tool, which will fail on mine because the required port is already being forwarded to another internal device on my network (i.e. NAS)?

[raspberrycoulis]

EDIT: Never mind, I appear to have resolved this. I changed the X-Forwarded-Proto to https but did not reload nginx. Running sudo nginx-s reload after making the change and then running ghost config url https://ghostpi.pro followed up by ghost restart now means that my blog is serving content over HTTPS properly again now. It wasn't earlier because I forgot to reload nginx!

@kevinansfield I’ve tried that suggestion but I get too many redirects now. The X-Forwarded-Proto in my config is set to $scheme; so I changed that to https; but that did nothing. This is my ngnix config (reverted back to how it was before) so if you could help explain what I need to change, that would be great:

server {
    listen 80;
    listen [::]:80;

    server_name ghostpi.pro;
    root /mnt/raid1/nginx/ghostpi/system/nginx-root;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368;

    }

    location ~ /.well-known {
        allow all;
    }