CiviCRM Community Forums (archive)

This is an outstanding bug in CiviCRM v1.9. We have not yet figured out a clean solution for this. So a patch for this would be greatly appreciated

lobo

This is still an open issue. A patch to fix this would be great

lobo

Good suggestion!  This approach seems like a useful solution.  I wasn't previously familiar with mod_rewrite, but dug into it and have a couple configurations that seems to be working for a Drupal site on a Plesk virtual host.

CONFIG A
Relying on the fact that all civicrm pages have "/civicrm/" in the path or "q=civicrm/ in the query (depending on whether CleanURL is enable in Drupal), then all civicrm pages can be encrypted and all non-civicrm pages can be unencrypted.

• Disable the Force Secure URLs option in CiviCRM global settings.
  
• Append these lines to conf/vhost.conf
  
  

RewriteEngine on

RewriteRule ^/civicrm/(.*) https://www.example.org$1/civicrm/$1

RewriteCond %{QUERY_STRING} ^q=civicrm/(.*) [NC]
RewriteRule (.*) https://www.example.org$1

The way that Plesk sets of the SSL configuration, the vhost.conf file is called for all non-encrypted pages, so all instructions in this file apply to http:// paths.  The first line turns on mod_rewrite.  Second line adds a rule that remaps any path with "/civicrm/" onto the secure path using "https".  The third and fourth lines do the same thing, but catch the case where a site is not using CleanURLs. If the query starts with "q=civicrm/" then do the same mapping.  If the Drupal site is not placed in the home folder, then corresponding changes to the "/civicrm/" path should be made.

• Append these lines to conf/vhost_ssl.conf

RewriteEngine on

rewriteCond %{SCRIPT_FILENAME} !^(.*)/civicrm/(.*) [NC]
rewriteCond %{QUERY_STRING} !^(.*)civicrm(.*) [NC]
rewriterule (.*) http://www.bcsustainableenergy.org$1 [L]
This file will be loaded whenever the page is encrypted, so we just have to catch the condition when we want to return to unencrypted path. The rewrite rule will be applied if both of the previous two conditions are met:  the path does not have "/civicrm/" and the query does not "q=civicrm". Note the "!" which does the NOT operation.

• Reload configuration into apache.  For Plesk this can be done with

/usr/local/psa/admin/sbin/websrvmng -a


For other server configurations, where the same configuration file handles both encrypted and enencrypted pages, the rewrite condition "rewriteCond %{SERVER_PORT} ^443$" may be useful.

CONFIG B
Allow CiviCRM to decide which pages should start being encrypted. Switch back to unencrypted once any page not on a civicrm path is visited.  This requires a hack to core code though.

- Enable Force Secure URLs option in CiviCRM global settings.
- Change CRM_Utils_System::redirectToSSL so that it doesn't check the base URL for SSL with the call to checkURL( $baseURL ).  I don't know the implications of this hack. There is a comment about checking this so that cookies work.?
- Don't implement mod_rewrite rules to switch from http to https.
- Implement the mod_rewrite rules listed above to switch from https to http.

CONFIG C (not implemented)
Allow CiviCRM to decide which pages should start being encrypted. Switch back to unencrypted once any transaction pages have been left.   Would also require the hack to core code.

- Enable Force Secure URLs option in CiviCRM global settings.
- Don't implement mod_rewrite rules to switch from http to https
- Make a list of all transaction page paths that can occur in CiviCRM and add revise granularity of the mod_rewrite rules listed above to switch from https to http. (I haven't done this)

OPTION D (not implemented)
The preferable option would be the internal fix to CiviCRM code. Would reduce the installation burden, and if there are issues with requiring 'cookies' at the base_url address with https this would resolve them.

I have discovered a much easier solution for Drupal that also works better: http://drupal.org/project/securepages Secure Pages module. 

While this relies on an external module, getting browser approved secure pages in CiviCRM is not fully independent from the rest of the CMS. For the browser to show a page as being secure (address bar turns different colour, lock icon appears, ..) all the content on a page must be run through https. Using mod rewrite does direct the base content of a page through https, but some of the Drupal 5 theme files have absolute addresses using http. This means that while the credit card info is secure, users don't get the security confidence indication.

Secure Pages module provides redirection lists exactly the way I developed in mod rewrite, but also takes care of redirecting internal Drupal pages, and has a very easy interface.

I specified the following pages in the Secure Pages list:

civicrm/event/register
civicrm/contribute/transact
civicrm/contribute/offline

and this solution elegantly meets CiviCRM security needs in Drupal.  If there was an equivalent Joomla module, this may cover security needs for CiviCRM, and at least for Drupal 5 I think is preferable to what could be done by CiviCRM itself.

In the future if Drupal fixes all their internal links to use relative paths (maybe in Drupal 6 ?), then an internal CiviCRM redirect would again become a useful option to consider.  The Secure Pages module would be a good base to draw from if this route was pursued.
 

Here's some recommended mods to htaccess for Joomla users:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^option=com_civicrm(.*) [NC]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://www.example.org/$1
This will only work if you are NOT using SEF for any civi pages, as it searches the query string for com_civicrm. With SEF on, urls are based on the alias field as you define it -- there's no consistent reference to the component in use -- so you can't really define criteria in the htaccess directives.

Also not that this changes *all* civi pages to https -- not just the contribution pages. That's not ideal, as https takes longer to load, which may be undesirable for admin pages where you don't need https (and don't want the slow down).

What I don't understand about this request is why you wouldn't want ALL pages in CiviCRM to be served over ssl (which I would love to know how to do). There is so much personally identifiable information in the database, why not err on the side of caution? What am I missing?

I'm glad I found this thread, as I will be attempting to 'switch-on' SSL, but not sure as to what to serve over https or http

Case #1:
CiviCRM is installed in a subdomain (vhosts) and ensure that this subdomain has it's own IP and certificate, or perhaps look into SNI (Server Name Indication)
Case #2:
Configure a separate vhost on a sub directory of your main domain, configuring SSL for this only. (Plesk 10 with FastCGI/suExec) Not sure how this would work with multiple clients sharing same install...
Case #3:
I know it will be a performance hit; serve the whole website over SSL. A few of the larger companies have done this and it seems to reinforce user-trust.

I will most likely be going for Case #2, then Case #3. Case #1 would be expensive...

Thanks for the heads-up on mod_rewrite and 'securepages'