search

TryGhost / Ghost

Independent technology for modern publishing, memberships, subscriptions and newsletters.
https://ghost.org
MIT License
47.64k stars 10.39k forks source link

Navigation links are forced to wrong protocol in reverse-proxy setups #7601

Closed rhuitl closed 8 years ago

rhuitl commented 8 years ago

URL in configuration is http://blog.example.com/blog. Ghost is behind a reverse proxy that terminates HTTPS, so outside world is using https://blog.example.com/blog and Ghost only gets HTTP requests.

My problem is that the "Home" link in the navigation bar does not work because it is http://blog.example.com/blog by default, which is not available to the outside world. This wouldn't be a problem, I would just change the link to https. However, when doing that and changing it to https://blog.example.com/blog, Ghost tries to be smart and changes it back to http://.

I also cannot change the URL in the configuration to https://, because then it seems that Ghost will issue a redirect to the https URL if it gets an HTTP request.

kevinansfield commented 8 years ago

Hi @rhuitl, sorry that you are having issues. The correct setup for SSL is to set your blog URL to the https version in the config file and pass the X-Forwarded-Proto header from your reverse proxy to Ghost, there is an example nginx config in the SSL Setup support docs.

Hop that helps. I'm closing this issue as what you are reporting is the expected behaviour.

rhuitl commented 8 years ago

Thanks for the quick reply. I don't understand why you need this strange magic for the links, it also doesn't allow relative addresses. Anyways, we'll set the X-Forwarded-Proto header as you suggested.

jlmagee commented 7 years ago

@kevinansfield Not meaning any disrespect, but what you define as correct is unlikely to prove to be issue free. I've worked a bit with several blogging and forum platforms over the last decade and every one that stuck with using a hard coded base URL had a variety of ongoing problems. Check the roller mailing lists from 2008-9 if you are really interested.

The only correct solution is to use only relative URLs in href attributes. Anything else is simply too much effort for a negative benefit.

It appears all of this use of @blog.url is in the theme anyway, so I'll see what I can do with the latest version of casper.

jloh commented 7 years ago

@jlmagee the core issue here is that ghost has no idea whether it's serving http/s requests due to the reverse proxy configuration. Using relative URLs don't even come into the equation. If the reverse proxy is setup correct and ghost had a URL with https everything would be working correctly as expected.

There's also a butt load of evidence to the contrary of everything you've stated, mostly where it can largely impact SEO (duplicate content etc). Relative and "hardcoded URLs" all have their own variety of issues but at least with hardcoded you know 100% where and what you're going to get.

jlmagee commented 7 years ago

@jloh there is no need for ghost to know what it is serving. Somehow you miss the point. It is all about relative links. The SEO stuff is smoke. There will be no duplicate content if the reverse proxy properly forces everything to one URL

The only need I've found so far is in the construction of the Feedly link.

kevinansfield commented 7 years ago

@jlmagee canonical URLs are output as absolute as per Google's recommendation and to avoid people with incorrect configs setting themselves up for duplicate content penalties, the only "hardcoded" value here is the one specified in a config file so not "hardcoded" in the traditional sense. All other internal links are stored and output as relative - if there are issues with that setup then it's a configuration problem at the proxy server level.

I'm afraid I'm failing to see the problem here, perhaps if you could give a concrete example? We've so far not had anyone have any problems outside of some simple config issues, if there were any major issues I think we'd see them come up a lot more often but definitely open to hearing about problems this setup is causing you.

jlmagee commented 7 years ago

@kevinansfield My original post was about relative versus fully-qualified or absolute URLs in anchors (or other references) on a page. I found these generated fully-qualified in the default casper theme. grep -R '{{@blog.url}}' content/themes/casper/* content/themes/casper/author.hbs: {{#if @blog.logo}}{{/if}} content/themes/casper/default.hbs:

{{@blog.title}} © {{date format="YYYY"}}
content/themes/casper/index.hbs: {{#if @blog.logo}}{{/if}} content/themes/casper/page.hbs: {{#if @blog.logo}}{{/if}} content/themes/casper/partials/navigation.hbs: content/themes/casper/partials/navigation.hbs: content/themes/casper/post.hbs: {{#if @blog.logo}}{{/if}} content/themes/casper/post.hbs: or subscribe via RSS with Feedly! content/themes/casper/tag.hbs: {{#if @blog.logo}}{{/if}}

Separately, I have a visceral objection to anything that, in my judgement, duplicates definition or requires seemingly unnecessary changes when, for example, migrating code from a preview to a production site. In this case the config is in the code. However, this is probably not the best thread in which to debate that view.

Thanks for the thoughtful feedback. You'll probably hear more from me on this topic in the future.