I have a site that needed to switch to Cloudflare DNS to accommodate an unexpected spike in traffic. Cloudflare is configured to force SSL on their end. This change was made by our hosting provider so I don’t have direct access to those settings. Using the rewrites below causes “too many redirects” errors, so I’ve disabled them in order to keep the site functional (Setting ssl='always' in config.ini causes the same issue).
.htaccess:
# these have been disabled due to incompatibility
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,NE,R=301]
But the issue I’m encountering now is that, even though the site is being served at https://, the paths are still output as http:// anywhere I’ve used WEB_ROOT as well as in plugin-generated output formats. This of course causes “mixed content warnings” and totally blocks active content (in my case, the JSON output that feeds my maps). For the moment, I’ve modified bootstrap.php where indicated below, which does fix the problem.
bootstrap.php:
// Set the scheme.
if ((isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] === true))
|| (isset($_SERVER['HTTP_SCHEME']) && $_SERVER['HTTP_SCHEME'] == 'https')
|| (isset($_SERVER['SERVER_PORT']) && $_SERVER['SERVER_PORT'] == 443)
) {
$scheme = 'https';
} else {
$scheme = 'http'; // manually changing to https fixes the issue
}
The question is, how can I do this in a more sustainable manner so things don’t break on the next update? Is there some other way to let the server/Omeka know to always use https://?
Those first .htaccess lines aren’t from us, I don’t think… I don’t recognize them, at any rate.
I believe you can just configure Cloudflare to connect to your site using HTTPS itself (I believe they call this “Full SSL” configuration). That would resolve the problem as Omeka would see the incoming connection as HTTPS. You said you don’t have access to those settings but you could possibly ask your provider to set things up that way.
Otherwise, can you check if Cloudflare is passing along a header, like X-Forwarded-Proto, to indicate that the connection HTTPS to the client even though it’s HTTP from Cloudflare? I have some work in progress to support X-Forwarded-Proto, but I have to cover some corner cases (like its effect on the “force SSL” configuration).
I’ve been helping Erin with this setup (the site in question is on Reclaim Hosting). I’ll try the Full SSL setting, it was a bit unclear when setting it up what options with Cloudflare are free versus paid when it comes to those settings (I know it wouldn’t let me upload a custom SSL cert but if I understand you right Full will just then pass through to the server for the cert which would be fine). According to https://support.cloudflare.com/hc/en-us/articles/200170986-How-does-Cloudflare-handle-HTTP-Request-headers- they do use X-Forwarded-Proto, but only for the Flexible SSL setting.
Thank you both. I’ve put everything back to normal, restoring my htaccess rules and removing the edit from bootstrap.php. Looks like everything is now working fine. Thanks again!
Great. This may help out other people looking to use Cloudflare with Omeka, too.
Basically, if you had SSL working before switching to Cloudflare, then you probably want to use the Full SSL (Strict) or Full SSL modes. This means you’ll get encryption along the entire connection from your users to Cloudflare to you, and you’ll avoid issues with Omeka using HTTP when you want HTTPS URLS.
As an aside, I’ll note that we’ve cut back quite a bit of our use of WEB_ROOT and absolute URLs, in favor of server-relative. This isn’t always possible but Omeka was previously using absolute URLs in a lot of unnecessary places (like linking to static assets) that are now server-relative and therefore don’t really care what Omeka “thinks” the connection is.