The Mixed Session module enables mixed HTTP(S) sessions for a site, securely and without loss of session data. The phrase "mixed sessions" refers to providing, with respect to a user visiting a site, some content over an insecure (HTTP) connection and other content over a secure (HTTPS) connection. For example, a shopping site may prefer to display product content in insecure mode (HTTP) while being able to protect sensitive content (e.g credit card details and authenticated user account information) using secure mode (HTTPS). The use of mixed sessions adds complications such as preserving session data (e.g. a cart ID) across session mode and protecting against session hijacking (with tools such as Firesheep). This module addresses both concerns.

The Mixed Session module protects against session hijacking by regenerating session IDs on step up and step down (i.e. switching between HTTP and HTTPS), providing a configuration switch to stay secure once having entered secure mode, and exposing more built-in, configurable redirect rules. This module also declares two API hooks through which a developer can incorporate more complex redirect rules. Protection applies to anonymous and authenticated users.

How is this different from...

These modules provide various configuration settings to indicate which pages to serve up over HTTP or HTTPS. The Secure Pages and UC SSL modules simply redirect to secure mode, but provide no protection against session hijacking. The Secure Pages Hijack Prevention module attempts to address the problem of session hijacking with Secure Pages (by creating a second session cookie with the "secure" flag set so it is only transmitted to SSL-protected pages). But this cookie is only created for authenticated users and only checked while logged in. The protection is incomplete for any user with Secure Pages alone and also for an anonymous user even with the companion Hijack Prevention module.

The 443 Session module attempts to improve on the Secure Pages combination, including utilizing the PHP "session.cookie_secure" setting and providing better support for anonymous users. However, enabling the "session.cookie_secure" setting has an unhelpful side effect. When a request comes in using HTTPS, Drupal core creates a second session record for the user in the "sessions" table of the database. This second session knows nothing about the first session. For example, if there is "data" associated with the first session, this is unknown to the secure session. During the switch (or "step up") from insecure to secure mode, this module (in conjunction with Drupal core) does not preserve the session data. Thus, the visitors to your site can add products to their cart over HTTP sessions, but their cart information is lost when they go to checkout using the new HTTPS session. They are greeted with a message like "There are no products in your shopping cart."

For anonymous users, none of these modules (in conjunction with Drupal core) provides a solution.

Typical configurations

The default configuration provides:

  • mixed sessions
  • secure redirection for pages with login and password forms
  • enter secure mode on cart/checkout
  • exit secure mode on cart/checkout/complete

Configuration

Before installation of the Mixed Session module, two preparatory steps need to be performed:

  • add a secure session ID column and index to the sessions table
  • apply a patch against Drupal core

The first step will be satisfied by installing the "Mixed Session Core" module (located in the "modules" subdirectory of this module), a dependency of this module.

Core patches are included in the patches subdirectory for the two latest releases (Drupal 6.22 and 6.24). To apply a patch against Drupal core, simply invoke:

patch -p1 < /path/to/this/patch/mixed_session_core-6-NN.patch

or refer to http://drupal.org/patch/apply for use with git.

The README.txt file included with the module provides further information.

Development

This module is sponsored by Boombatower Development.

Project Information

Downloads