Thursday, February 24, 2011

Drupal: How to enable Clean Urls Module

  1. Edit apache configuration
    ee /usr/local/etc/apache22/httpd.conf

    and set
    AllowOverride All

  2. Make sure
    LoadModule rewrite_module modules/mod_rewrite.so

    is enable.

  3. Edit .htaccess file and change

    # RewriteBase /

    to
    RewriteBase /

  4. Restart Server


Another way

If you have locked yourself out, visit http://example.com/?q=user just like you do to re-enable offline sites. You can log in there, enough to become admin, although none of the navigation will work yet.

Next, enter http://example.com/?q=admin/settings/clean-urls (in DRUPAL 5 and 6) to view the page where you can unset clean URLs.
Your interface will be usable again.

Other options that should get the same result include:

  • Run the drush commands:
    drush vset clean_url 1 --yes

  • Run the mysql commands:
    UPDATE variable SET value = 's:1:"0";' WHERE name = 'clean_url';
    DELETE FROM cache;

  • Alternatively, you can modify the appropriate settings.php file to include the line
    $conf['clean_url'] = 0;
    at the bottom (or similar code in the site settings array you'll see there).

    .

Monday, February 7, 2011

How to enable HTTPS support in Drupal

Web server configuration

  1. Get a certificate. many hosting providers set these up for you - either automatically or for a fee. Simply ask your hosting provider.

  2. Configure your web server. A few helpful links:

    Chances are, your webhost will do this for you if you are on shared hosting.

Drupal configuration

  • If you want to support mixed-mode HTTPS and HTTP sessions open up sites/default/settings.php and add $conf['https'] = TRUE;.
    This enables you use the same session over HTTP and HTTPS both -- but with two cookies where the HTTPS cookie is sent over HTTPS only. You will need to use contributed modules like securepages to do anything useful with this mode, like submitting forms over HTTPS and so on. While your HTTP cookie is still vulnerable to all usual attacks, a hijacked insecure session cookie can only be used to gain authenticated access to the HTTP site. It will not be valid on the HTTPS site. Whether this is a problem or not depends on the needs of your site and the various module configurations. For example, if all forms are set to go through HTTPS and your visitors can see the same information as logged in users then this is not a problem.

  • For even better security, leave $conf['https'] at the default value (FALSE) and send all authenticated traffic through HTTPS and use HTTP for anonymous sessions. Once again contributed modules like Secure Login can help you here. Drupal 7 automatically enables the session.cookie_secure PHP configuration on HTTPS sites, which causes SSL-only secure session cookies to be issued to the browser.

  • For best-possible security, setup your site to only use HTTPS, not even responding to HTTP with a redirect. HTTPS is vulnerable to man-in-the-middle attacks if the connection starts out as a HTTP connection before being redirected to HTTPS. $conf['https'] can be left at its default value (FALSE) on pure-HTTPS sites.

    .