Home

developers.mit.edu

Sort of helping developers at MIT since 2009

Secondary links

  • Forums
  • Recent Posts
Home Forums Web Masters
    • FAQ
    • Contact
    • Community

How to Force SSL on User and Admin Pages of Drupal

Submitted by bknoll@mit.edu on Thu, 01/22/2009 - 13:08
  • Web Masters
  • SSL Drupal Apache

This is a description of how to force SSL on the User and Admin pages of Drupal, while allowing non-SSL access to other parts of the site.

There are some caveats to this configuration. It will not force the user back to non-SSL once the user is redirected to a secure page. However, it does not prevent the user from entering a non-SSL URL in the URL box, so long as that URL is not to the "user" or "admin" paths within Drupal. This has the effect that the connection will automatically become SSL-protected when either of these two sections are accessed, and that the session will tend to remain SSL for the rest of the time the site is used during that session. This causes two possibly negative effects.

Firstly, if a user manually changes their URL box entry in their browser to the "http://" equivalent of a location not within the "user" or "admin" spaces, their session will no longer be encypted. Some non-public data could be transferred in cleartext over the browser session. Since the user manually changed the URL box, presumably they understand the risks here and have chosen to accept them.

Secondly, if a user logs into Drupal, their session will become SSL-protected, because they access the "user" section to do so. However, if they then close their browser window or browse to another location, then return to the site, their session will no longer be SSL-protected. This is an unintentional instance of the first example above. As above, there is a possibility that some non-public data could be transferred over the wire in cleartext in this scenario. Of course, were the user to then navigate to the "user" or "admin" sections, their session would from that point become encrypted. This scenario involves a user unwittingly making their session insecure.

The team(s) or individual(s) managing the site are responsible for considering these risks, as well as the associated consequences, and choosing the appropriate course of action.

Here is how to install this configuration, if you choose to continue:

In the httpd-vhosts.conf file, configure your port 80 virtual host as follows:

RewriteEngine On
Redirect /user https://sitename.mit.edu/user
Redirect /admin https://sitename.mit.edu/admin

Enable "Clean URLs" in the web admin interface of Drupal.

Install the "globalredirect" module into the modules directory used for the site you're configuring. For example, if your drupal installation is under /var/www/drupal, then you might use /var/www/drupal/sites/all/modules as the directory to extract the module, so that the module would be located in /var/www/drupal/sites/all/modules/globalredirect, and would be used by all sites. Here is an example, assuming your module is called "globalredirect.tgz" and is located in /usr/local/src:

cd /var/www/drupal/sites/all/modules
tar -xfvz /usr/local/src/globalredirect.tgz

Run update.php on the site from a web browser.

Enable both the "path" and "globalredirect" modules in the Admin interface of Drupal.

‹ Mysterious Apache Hang - Clearing semaphores fixed polyeidus.mit.edu openssl question ›
  • Login to post comments

odd admin section behavior with https

Submitted by asphodel@mit.edu on Fri, 02/13/2009 - 14:38.

I was testing a site with these redirects in place, but noticed the admin section behaving strangely under https, where many edits would be ignored on the first submit, but go through on the second submit. For instance:

- I go to user management and look at the list of users
- I select a user to edit
- I change the role of the user
- I submit

The role of the user doesn't change.

I go through these steps again, and somehow on the second try it works.

Also saw the behavior editing existing and saving new blocks. The problems disappeared once we disabled the redirect on the admin.

Wondering if anyone else has seen this behavior?

  • Login to post comments

Login

Log in via Touchstone

Forums

  • All Forums
  • General Questions
  • Drupal Users
  • FileMaker Developers
  • Identity Management
  • Java Developers
  • Linux Users
  • Opportunities
  • PHP Developers
  • Python Users
  • UX Developers
  • Web Masters
  • Suggestions

Tags

accessibility ajax branch Javascript jQuery MIT Touchstone openssl question from an openssl noob release management Shibboleth silverstripe source control speed
more tags
RoopleTheme