I am in the process of converting a number of sites to site wide HTTPS and am running into some issues with redirects, URL's and so forth.
This is as much a discussion as it is a will hire you if you can let me know what you experience is with this end of core apache/drupal stuff.
There are 5 sites with various levels of complexity and I have gone so far but am now stuck.....
Happy to be contacted here (drupal.org)
marc@webkitchen.ca
or
613-294-8557
UPDATE: Example CODE to comment on
# ENGLISH DOMAINS
RewriteCond %{HTTP_HOST} www.DOMAIN-ENGLISH.ca$ [OR]
RewriteCond %{HTTP_HOST} DOMAIN-ENGLISH.ca$ [OR]
RewriteCond %{HTTP_HOST} www.DOMAIN-ENGLISH.com$ [OR]
RewriteCond %{HTTP_HOST} DOMAIN-ENGLISH.com$ [OR]
# FRENCH DOMAINS
RewriteCond %{HTTP_HOST} www.DOMAIN-FRENCH.org$ [OR]
RewriteCond %{HTTP_HOST} DOMAIN-FRENCH.org$ [OR]
RewriteCond %{HTTP_HOST} www.DOMAIN-FRENCH.ca$ [OR]
RewriteCond %{HTTP_HOST} DOMAIN-FRENCH.ca$ [OR]
RewriteCond %{HTTP_HOST} www.DOMAIN-FRENCH.com$ [OR]
RewriteCond %{HTTP_HOST} DOMAIN-FRENCH.com$
# REWRITE TO ORG DOMAIN
RewriteRule ^(.*)$ http://DOMAIN-ENGLISH.org/$1 [R=301,L]
# REWRITE TO HTTPS
# RewriteCond %{HTTPS} off [OR]
# RewriteCond %{HTTP_HOST} ^www.DOMAIN-ENGLISH.org*
# RewriteRule ^(.*)$ https://DOMAIN-ENGLISH/$1 [L,R=301]
Comments
I wouldn't muck with
I wouldn't muck with .htaccess files, that would make your sites harder to maintain and upgrade.
If you've got access to your apache config files, then it would be relatively straightforward to set redirects, but you can also use the securepages module to do selective redirects which is sometimes a good idea (but you have to worry more about session hijacking).
re: I wouldn't muck with .htaccess files
Shared hosting environment... and apache config files are even more beyond me :) so sticking with what I know and can update if it gets botched on a CORE update (and it will)
The internal modules are difficult as they end up being selective and have as many issues with stray urls.
Thank you - looking for options and looking at doing such work in the settings.php file as I have seen discussions on that.
Ie. https://pantheon.io/docs/articles/sites/code/redirect-incoming-requests/
Recommend Apache solution
It is not especially hard to accomplish HTTPS redirect in Apache/Nginx and that is definitely the recommended solution.
If you cannot access the web server, and want to still have some pages with HTTP access, you could try the securepages module. Last time I tried, it seemed to work fairly well.
Well...
I'm not so sure about "harder to maintain and upgrade".
Managing HTTPS configuration in the .htaccess or settings.php files is relatively simple if you're well organized (and they're the only option on some hosting platforms).
Secure Pages module is certainly a great option too for site builders.
Edit: Just a quick edit to note agreement with cleanforestsol's comment below.
Modifying the Apache config
Modifying the Apache config files will make it harder to change hosting environments in the future, or copy the website to a staging server or local development environment, etc. It is better to keep the code in the .htaccess file with the rest of your project files. This will also mean that the code can be checked into your version control repository.
@mbehiels, your first RewriteRule should be httpS as well.
RewriteRule ^(.*)$ https://DOMAIN-ENGLISH.org/$1 [R=301,L]
Best,
Noam
noam@cleanforest.co
This looks a little
This looks a little dangerous. You want a RewriteCond before that line to restrict to your non-ssl requests, or you'll put yourself in an infinite loop.
Don't edit .htaccess
I don't agree with modifying core's .htaccess. Although it may be necessary in this situation, you generally don't want to modify upstream code as it'll get overwritten during upgrades. Then you'd have to remember to cherry-pick your custom changes after each one, and you may have to deal with merge conflicts at some point.
Ideally, I'd recommend the following in your virtual host configuration file:
If you let Drupal's .htaccess run on its own, as it normally does (without disallowing it), it'll run after your configuration. You want it to happen the other way around: Core first, and then any of your overrides.
Yes, you'd have to bring the virtual host configuration if you move providers, but that's just part of the site configuration you'd bring anyway. I like to store this stuff in sites/all/config, and then have symbolic links from the various parts of the OS to there. The Web server can be configured to block access to the folder. This will keep everything in your Git repository, PHP and configuration. (For the record, I also keep Drush configuration in sites/all/drush.)
Hi @adixon,My RewriteRule
Hi @adixon,
My RewriteRule was just a modification of @mbehiels's first RewriteRule posted above. It should be preceded by his RewriteConds.
Thank You!
everyone - have had overwhelming responses here and via email.
Working with Dave (@spotzero) @ColdFront to sort things out.
@cleanforestsol yes this was my concern that if clients wanted to move post maintenance or dev contracts things would get buggy/broken
@Chris Luckhardt - im organized and NOT a programmer im a UX Design guy (see my issue here :) )
@adixon the guys @Blacksun who manage my 4 dedicated servers would slay me if I touched the Apache Config files and so would the other 250 clients... lol
Marc Behiels
Settings.php approach
Hello all,
I'm chiming in a bit late but I disagree with some of the suggestions...
When I need to attempt mixed mode I've used Secure Login, but per above I don't think it is advisable to bounce between http and https, and additionally any time there is a form on the page it will force you to https.
It is simply easier to be https-only.
Now with that being said, I've had my fair share of problems with people accidentally blowing away the .htaccess file.
The solution I have come to is to use settings.php always.
For Pantheon this is the code I use:
// Require SSL.
if (!isset($_SERVER['HTTP_X_SSL']) ||
(isset($_SERVER['HTTP_X_SSL']) && $_SERVER['HTTP_X_SSL'] != 'ON')) {
header('HTTP/1.0 301 Moved Permanently');
header('Location: https://example.com'. $_SERVER['REQUEST_URI']);
exit();
}
Now, be forewarned those $_SERVER variables might be Pantheon-specific (though I don't think they are), I pretty much only use Pantheon these days so just double check if it doesn't do what you want. Based on what I see in your original description you may want to use a different $_SERVER variable to target incoming domains, etc, rather than testing if https is supported. That will enable you to target your specific situations better.
At least if it is in settings.php you won't need to worry about someone accidentally deleting it, provided they don't overwrite your settings.php file with their own. Additionally, you are secure against https stripping attacks.
I'm also primarily with
I'm also primarily with Pantheon and do most config in settings.php.
Just to add to Ryan's comment here are a couple of helpful resources:
Fascinating how a smallish
Fascinating how a smallish question can generate so much discussion. Clearly there is more than one way to do this, and it'll depend on your server and development style as to which one works for you, and every option has it's caveats.
Ryan: thanks for elaborating my throw-away comment about session hijacking. Mixed mode definitely needs some understanding and thought, and in recent 7.x releases, Drupal now makes it pretty hard to do mixed mode (i.e. it'll force separate cookies for https by default). Setting all ssl is definitely one option, but it does add unnecessary server load and potential confusion in some cases. My preferred solution for most public sites these days is to use secure pages to force ssl for all authenticated access as well as any page with a login form (and restrict that to just the user page).
Let's Encrypt
It's much easier to do HTTPS everywhere now (free certificates and automation) thanks to the Let’s Encrypt folks. Though, I don't think they have the Nginx plug-in working just yet. The Apache one seems fine.
Site-wide HTTPS in yhe vhost definition
Do not use .htaccess or the main Apache conf file (except for vhosts).
You can configure site-wide redirection from HTTP to HTTPS in the vhost definition of your site by adding 3 lines:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
It is very rare we need to modify the vhost definition for a site, so that type of redirection is a good fit for the vhost definitions.
Furthermore, you do not need PHP pages as redirections in vhost will apply to static files, HTML files and others that do not pass by Drupal or PHP.
Cheers,
— Jacques
/* http://www.xmacinfo.com */