Forcing SSL in the usual ways causes redirect loop only on Cloud9


#1

I’ve had this issue on multiple projects, though mainly PHP projects running on Apache. On any other server, I could easily force SSL using:

.htaccess something like this

RewriteEngine On

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301,NE]

Or in the apache conf something like this

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

Or most frameworks will offer some kind of SSL redirection built in to force all routes to SSL.

The problem is that ALL of these create a redirect loop or an SSL error on Cloud9, I suspect because of the way that Cloud9 handles SSL for all of the workspace preview subdomains and the way that they handle the ports. If it’s fixable at the apache, htaccess, or application level then great - but it seems like there’s some other level of routing the subdomains that’s causing this behavior.

If the redirect ends up adding a port in the URL, which seems to be whenever there’s a trailing slash, it gives an SSL error. Otherwise it seems to redirect loop.

I’m looking for a definitive answer from a Cloud9 employee on how to handle this, since all of the other threads touching on this don’t have one. I’ve had other people I’ve referred to C9 ask me about this problem and I don’t have an answer for them. Lets get one down here please.


#2

I’ve tried, but i don’t know apache well and couldn’t find a way to get HTTP_HOST without :80, writing hostname manually instead of %{HTTP_HOST} works, but that’s probably not the solution you are looking for.
Why do you want to have http redirection when working on cloud9? Thwaye preview can’t be used for hosting production sites anyway


#3

I’m not trying to use C9 for hosting production sites, but there’s many browser features and services these days that require SSL even to test during development. For example, WebRTC, Stripe, many more.

I’ve also got a number of large projects that I’ve inherited and develop on C9 that have thousands of links - dynamically generated, or relative hard coded links - that previous devs have not bothered to make https links. It would be a massive effort to rewrite them all when we should be able to use forced SSL on all links.

Anyways, I wouldn’t be opposed to manually entering the hostname if I can do it in the apache conf, which isn’t going to be in version control ever.

However using C9_HOSTNAME instead I just tried with this and it worked:

RewriteEngine On
    RewriteCond %{HTTP:X-Forwarded-Proto} !https
    RewriteRule ^/?(.*) https://${C9_HOSTNAME}/$1 [R,L]

The rewrite condition using %{HTTP:X-Forwarded-Proto} seems to detect C9’s subdomain SSL routing properly so it won’t redirect infinitely. The rewrite rule just uses the C9_HOSTNAME to get the base URL, prepends https:// to it, and adds whatever you already had after the slash. This particular version also makes the trailing slash optional, and it should work in either the apache conf or htaccess.

NOTE: I did have to clear my browser cache for some reason before this worked, which I’m not really sure why, but give that a shot if this isn’t working for you. Also, make sure you restart apache as usual after making this change.

I haven’t tested this too heavily so the :80 getting added to routes might still be an issue, but I haven’t run into it since. If I do, I’ll update this post.