October: Backend Breaks With SSL

[abass]

I've been looking for support and a way to fix this for a few days now with no avail.

The assets that are being called when you visit /backend are all called in via http://

This causes it to be broken as the browser won't load insecure assets over https://

The fix I did in Laravel does not work in OctoberCMS and making any forcing changes within the backend files just cause it to reset anyway when you run composer (of which happens every time you push your updated site to Heroku).

Howcome it even lists the complete directory by default on October anyway? Rather than listing "http://example.com/modules/foo/bar/.css&.js" why not have it by default just be "/modules/foo/bar/.css&.js" and then you wouldn't even have to deal with the native assets switching between http:// and https://.

[daftspunk]

As discussed, this is generally inconsistent across the platform, I think because Laravel nor October have an opinion on this. Maybe we need to discuss the idea of a link policy?

• relative: All links are created relative, hostname is omitted
• detect: All links are generated to the detected hostname and use the current scheme
• secure: All links are generated to the detected hostname and are HTTPS
• insecure: All links are generated to the detected hostname and are HTTP
• force: All links are generated to a specified hostname (see config app.url)

[abass]

Interesting. Yeah, I would be curious to hear what others have to say on the matter.

I have always been a large proponent in the past of having a relative link in all of my files. Not to mention, OctoberCMS already does that when embedding with /combine/ and various other assets on the front-end. It just doesn't on the /backend for some reason.

I have only run into this problem since switching to a framework because the framework has made the decision for me. This has done nothing but cause problems when moving a site over to SSL and keeping a separate non SSL version of the site for when I'm using localhost. I am now left with a problem I never had in the past and extra coding to make it change depending development environments simply because links to files within the same site feel the need to list the entire hostname.

Now when preparing a site for SSL, a smart thing to do with external asset files is to do //cdn.externalwebsite.com/asset.css which takes a look at the URL and decides whether it needs to grab the http version or the https version if it exists. This is how I embed all external fonts, JS, CSS, etc. That being said, why should we allow all external asset links to be smart when dealing with the hostname and only run into problems (like I am now) with internal links? I don't really see a downside to it being done automatically (via relative).

It also appears much cleaner on the back-end and you don't run into annoying problems where you need to deal with separate environments for two+ app.urls, one for localhost, one for development server, and one for production server. 99% of the time your localhost will not have https:// on it so you'd at the very least need a separate file for localhost as for production which is just.. An unnecessary pain.

I guess the real question would be, when would you ever want to force insecure local assets over a secure (https) connection? Or when would you want to force secure local assets over an insecure (http) connection? I can't think of a possible time where someone would purposely want to do this? So this is why in my eyes, the 2nd & 3rd option don't make much sense. But maybe someone else can enlighten me?

As for the 4th option, pretty sure that's what Laravel does out of the box, but October seems to break (for the backend atleast). I have switched the app.url between http and https without any effect in the local asset management. But even so, by going this route, you immediately begin dealing with the need for a separate local environment config app.php file and one for production. So that creates an unnecessary barrier to entry for someone using the framework. They now need to learn how to set up two environments for such an annoying reason. A reason which would not even need to exist if it just dealt with the relative path out of the box instead of juggling with hostnames.

TL;DR: I am completely sold on the relative path, option number 1 unless someone else could in some way educate me on why that's for some reason a terrible idea? (I really don't feel like someone is going to fight against relative because thinking logically, it just makes no sense to force one over the other or dealing with multiple environments instead of having it just automatically decide). The relative path does all the thinking for the user and it would reduce the barrier of entry for people (like me) who are primarily front-end developers, but know enough PHP to get them by. I feel like Laravel was a bit overwhelming to me as a front-end dev, but I learned to love it. Now with OctoberCMS, I have a Laravel background and getting frustrated that the automatic hostname fix I discovered on Laravel does not work on OctoberCMS. Why not just have a site work fine on/off SSL out of the box (using relative) instead of having to deal with the mess that comes from the other route?

Really appreciate you taking this point seriously @daftspunk - I have been very much enjoying OctoberCMS & recommending it to every developer I know :+1:

[JanvanCasteren]

One plus for this from me. I am making my first (personal) site with Octobercms and I really like it very much.
In two months I will start working on a serious webapplication for a client. I am coming from Kohana and planned to make the switch to Laravel. But Octobercms seems so flexible and powerfull to me, that it makes a good candidate to make that application with. But only if it will be possible to use the backend on https.

[abass]

Yeah, I just logged out of the backend and can't even log back into my site unless I go to CloudFlare, disable SSL, visit my site in http:// and then login that way before finally turning back on https:// and accepting the browser to load unsafe assets.

True SSL is pretty much useless until the backend assets are called in relative which is becoming more and more important now that SSL on even generic sites is highly recommended by Google.

Looking to use OctoberCMS on my client's site that's coming up in a couple weeks so really hope it gets settled by then.

Thanks!

[StudioLE]

I'm also finding this bug debilitating. October CMS / Laravel don't seem to realise that the site is running on SSL. URL::asset() and Backend::skinAsset() return http:// urls rather than https://

I'm using Ubuntu, Nginx & CloudFlare Flexible SSL. I assume it's the Flexible SSL causing the issue?

Flexible SSL: There is an encrypted connection between your site visitors and CloudFlare, but not from CloudFlare to your server.
More information on CloudFlare

[abass]

@StudioLE yeah exactly. I'm in the same position using CloudFlare. I'm sure that's it, you bring up a good point. It's definitely due to the SSL to CloudFlare but not to the server because I tried like 20 different things but the site never actually realized it was on SSL and adjusted assets accordingly.

The easiest fix this would be to force everything from it's relative directory path as mentioned above because you wouldn't need to deal with http vs https URLs at all from local assets. But that's entirely up to the framework doing it this way. It'd be a huge pain to do it yourself as it'd be reverted next update or everything composer updates the backend. Kinda at a standstill. I guess all we can do is explain to the dev of how big of a problem this really is.

[ChipWolf]

Same issue here. Cloudflare flexi SSL.

[ChipWolf]

I produced a terribly patchy workaround by tampering with Laravel's UrlGenerator.php. It was the quickest fix for me.

Rename the URL::to function to unsecureTo and force any uses of to to be secure. Duplicating URL::secureTo essentially.
Same goes for assets. I apologize for how cringeworthy this fix is, but it works.

A production fix for OctoberCMS would be to create it's own functions for deciding if to use URL::to or URL::secureTo and URL::secureAsset over URL::asset. This would be achieved with a 'secure' (true/false) config option and/or checking if the URL issued in the config starts with https

[abass]

@MichaelBanks interesting. You mention that a production fix would be to check the config and see if it starts with https or not. Wouldn't a better production fix just be to output a relative url though, omitting the hostname entirely?

e.g. instead of

<link src="https://www.example.com/directory/to/backend/assets">

have it just do

<link src="/directory/to/backend/assets">

Because with that fix, you don't have to deal with true/false or specify in the config if your site will be on SSL or not. I mean relative routes are the perfect fix for this in theory, is it not? I honestly don't see a downside.. Why would anyone ever want to force a local asset over non-SSL if their site is SSL, and vice-versa? It seems to make no sense defining http or https assets on the site level.

It's the same reason that links like:

<link src="//cdnjs.cloudflare.com/ajax/libs/jquery/2.1.3/jquery.min.js">

exist.. Just using // takes it upon the browser to choose whether it needs a secure or insecure asset. It functions just as a relative link works.

So from your suggestion for the production fix, I ask why even use unnecessary PHP statements and configs to define whether an asset is secure or not when it's not even needed because browsers have done that natively since the beginning of time if you use the relative or // path. Using one of those two paths would make it work out of the box for everyone. They wouldn't even have to worry about dealing with defining their site as SSL or not, it just works automatically, as it should.

[ChipWolf]

@flip4bytes I do agree rel links would be a nice feature. But, I'd prefer if I could configure to use relative links/definite links or // links

@daftspunk change the tags on this issue please? It's a definite bug, less of a feature request.

[abass]

@MichaelBanks just curious if you can come up with even one scenario where it makes sense to configure it? Not trying to be argumentative, just trying to spark a discussion and save @daftspunk time having to create unnecessary options.

Can you come up with an example of where the developer would ever want to force secure server assets over an insecure connection or force insecure server assets over a secure connection instead of it just detecting your connection and doing it automatically? I've been thinking about it for months now and can't come up with even one example where that would EVER make sense. Therefore it would be a waste of time implementing anything but the relative path option. Just saying what you prefer doesn't give it the proper backing and I feel like @daftspunk is waiting for an actual discussion of the best route before fixing this bug.

Interested in hearing your ideas.

[ChipWolf]

@flip4bytes the only purpose I can think from the top of my head is shifting assets off-site. (to a CDN for example)

EDIT: apologies for the late response

//cc: @daftspunk

[abass]

@MichaelBanks but this suggestion is just for how on-site assets are handled anyway. Calling in off-site assets would still work the same as it always has, just linking to the whole URL and choosing then if it's http or https. This is only about how on-site assets are handled, aka relative still makes the most sense.

I'm using a CDN as usual for various assets like jquery, that's unrelated though to this problem, this problem is ONLY for on-site assets.

[ChipWolf]

@flip4bytes I agree, I can't imagine what I was thinking the first time around.
Nice to see @daftspunk making progress on this issue :+1:

[abass]

@MichaelBanks appreciate the discussion though! And @daftspunk thank you so much for moving forward on this! Can't want for the update, excited to start using the /backend again without having to first disable CloudFlare SSL. (:

[ChipWolf]

https://github.com/octobercms/october/commit/47eff923e5b8a7a90bb931fac40628938ff16678 Policy reverted due to breaks.

@daftspunk can you elaborate?

[abass]

@daftspunk @MichaelBanks So I have updated to build 230 and the problem still exists but I can confirm the exact reason why. detect mode does not work properly if you are just using CloudFlare's Flexible SSL as per @StudioLE (just as he mentioned before):

Flexible SSL: There is an encrypted connection between your site visitors and CloudFlare, but not from CloudFlare to your server.

I guess this is a perfect example of why having a relative link policy is preferred (though I understand you were having some problems getting it to work). The server is seeing it as not SSL, but the site visitor and browser is seeing the site as SSL (because CloudFlare to visitor pushes https). Because of that, October with the detect policy in place detects the site as non-SSL (from server to CloudFlare) when in reality it's being delivered as SSL to the end-user, causing problems. Using a relative link policy is the only way to fix that specific case scenario. Unless of course you forced a secure connection but then you have to deal with enabling SSL too in your local environment OR setting up different environments to toggle SSL on and off.

EDIT: The only solution to this problem (if there is no way to get a relative link policy working) is to install a proper SSL certificate onto your site. Once that is done, linkPolicy => detect works like a charm. Only after you have a proper SSL Cert installed on your site is when you can then enable CloudFlare's Flexible SSL. But make sure you then go to your SSL connection within CloudFlare and switch it from Flexible SSL to Full SSL. At the end of the day, CloudFlare's whole free Flexible SSL screws up with how assets are delivered from the server to CloudFlare because from the server to CloudFlare is still an http:// connection.

[ghost]

I am having the same issue. Would be nice to be able to fix without any extreme tinkering.

[dylanjacob]

+1 from me too. SSL on the backend is a biggie for me to feel confident in using October CMS as my goto for clients.

[itsphi1989]

Adding this code to my .htaccess forces redirects everything to https including backend.


RewriteCond %{HTTPS} !=on


RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]


Let me know if this helped anyone :/

[toome123]

It's about one year ago, have any possible fix ?

[StudioLE]

@toome123 If I recall correctly, in /config/cms.php you can now force HTTPS links by setting:

'linkPolicy' => 'secure'

[abass]

@toome123 I just avoided all of that mess by getting an SSL certificate. If you are using Laravel Forge, they just integrated "Auto-renewing Let's Encrypt SSL certificates" which are 100% FREE SSL Certs and it makes it incredibly easy. Just click "SSL Cert --> LetsEncrypt --> Activate" then you can just force full SSL from CloudFlare and you're good to go. Takes not even 40 seconds to get up and working on each site.

[daftspunk]

This only controls how links are generated, it does not enforce any redirects as this would be too magical. This is up to your web server configuration to handle.

[Eoler]

This works well with Apache:

OctoberCMS config:

    'cms.linkPolicy' => 'force',
    'app.url' => 'https://...',

.htaccess

    ## Force secure connection
    RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
    RewriteCond %{HTTP:X-Forwarded-Proto} =""
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

[srsgores]

For me, setting cms.linkPolicy to 'secure' did the trick. Also, it fixed the responsiveImages plugin from having the same problem

[Samuell1]

Best simple fix is to force SSL on server or dns side and dont forget to change in _config/cms.php_ backendForceSecure to false