Follow us on Twitter!
Syndicate content
Login - Register - Latests submissions

Going live

By default Drupal will keep people logged in for 23 days (2000000 seconds) by saving a cookie in their browser. This is nice, but a potential security problem if people are using the site from shared computers.

Consider editing the site's settings.php to have

ini_set('session.cookie_lifetime',  0);

instead of the default

ini_set('session.cookie_lifetime', 2000000);

With the former, the user's login will be forgotten when they close their browser window, even if they forget to log out explicitly.

  • Go to Site configuration > Error reporting
  • Set Error reporting list box to Write errors to log
  • Save configuration

It is recommended that you prevent users from registering on your website with some odd usernames like:

  • root
  • admin
  • administrator
  • webmaster

To prevent this from happening:

  • Go to Administer > User management > Access rules > Add rule
  • Set Access type to Deny
  • Set Rule type to Username
  • In Mask type root
  • Click the Add rule button

Repeat this for every username you don't want to be created on your site.

Drupal comes with a set of TXT files at root level (things like install instructions, upgrade instructions, etc.). To avoid malicious users to have information on the Drupal version you are using, it is strongly recommended to remove those files.

From the root directory of your installation, remove the following files:

  • CHANGELOG.txt
  • COPYRIGHT.txt
  • INSTALL.mysql.txt
  • INSTALL.pgsql.txt
  • INSTALL.txt
  • LICENSE.txt
  • MAINTAINERS.txt
  • UPGRADE.txt

Whether or not these files contains security information (like Drupal version for example), the all contain a CVS header that gives a really precise version information on your Drupal installation.

Cron is a deamon which triggers certain actions (cron jobs) at configured times. Windows has an equivalent system called Task Scheduler. Calling cron.php at regular intervals will allow, amongst others, the indexation of content the content and to check for updates.

Setting up a cron job under a *nix system is fairly easy.

  1. Create or edit a crontab by typing in a terminal crontab -e
  2. Assuming that you have one of the following programs on your system, add one of the following line to trigger a request to cron.php every hour:
    • 0 * * * * /usr/bin/wget -O - -q -t 1 http://example.com/cron.php
    • 0 * * * *  /usr/bin/lynx -source http://example.com/cron.php
    • 0 * * * * curl --silent --compressed http://example.com/cron.php
  3. Save and exit your editor.

Setting up cron jobs on Windows is almost as easy! See Resources below.

Drupal logs information about cron jobs. Once you have configured it, you should see entries in your logs (Administer > Reports > Status report and Administer > Reports > Recent log entries) indicating the status of the related tasks.

fp

You can gain performances by disabling unecessary contributed modules from your live site. Here is a list of modules you can safely disable on a production site:

  • Devel
  • Devel generate
  • Devel node access
  • Performance Logging
  • Theme developer
  • Advanced help example
  • ImageCache UI
  • Views UI

There are a number of settings for contact forms that are easy to miss, since they aren't readily visible on the site. After you are sure that all the settings are right, you should also submit a test contact on every unique contact form to make sure the email address actually works.

The Site Information settings page at /admin/settings/site-information contains the from address setting.

/admin/build/contact has "To:" addresses and auto-responders, etc.

If you use Webforms, there are similar settings at /admin/settings/webform and per-node at /admin/content/webform (minimally, check the to address in each webform node).

Create a node (a page content type for example) with some extra information so that your visitors don't ever fall on the default 404 page not found.

Once this node is created:

  • Remember its node ID,
  • Go to Administer > Site configuration > Error reporting
  • Set Default 404 (not found) page to the node ID you just created
  • Save your settings

You can alternatively use the Search 404 module.

Considering the domain name drupal-check.org, we want to redirect all users accessing your website from http://drupal-check.org to http://www.drupal-check.org.

Edit .htaccess file from the root directory of your Drupal installation, find the <IfModule mod_rewrite.c> section and uncomment the following lines, replacing example.com with your own domain name, in this example drupal-check.org:

RewriteCond %{HTTP_HOST} ^drupal-check\.org$ [NC]
RewriteRule ^(.*)$ http://www.drupal-check.org/$1 [L,R=301]

More information is provided in the .htaccess file itself.

It's highly recommended that you protect user with uid 1, i.e. the one who has life and death rights on your Drupal installation.

Disallow user 1 deletion:

Disable user 1:

  • Be sure to have at least one user (other than uid 1) that has the permission administer users from user module.
  • Login with this account (again other than uid 1)
  • Go to Administer > User management > Users
  • Edit user with uid == 1
  • Set Status to Blocked
  • Click Save

Now user 1 can't login to your website. No more risk for password discovery for this account.

Please note that you should check enabled modules code, sometimes they use user 1 to achieve some tasks. And this could break some modules features. So use with caution.

It is strongly recommended that you put your site off-line before performing any module/theme updates.

  • Go to Administer > Site configuration > Site maintenance
  • Set Site status to Off-line
  • Save your settings
  • Make a backup of your database and file structure
  • Upload new files to your server
  • As user 1, run http://www.example.com/update.php
  • Be sure to check that everything works fine after the update process
  • Go to Administer > Site configuration > Site maintenance
  • Set Site status to Online
  • Save your settings

Check API keys (e.g. Google Maps API key) particular keys which assigned to a domain.

During site development, test content will have to be created so that features can be tested and styled. However, you don't want that test content to go live!

First off, avoid making any content that could potentially be damaging if it accidentally went live. The Devel module can generate content of most types for you automatically, in a way that is clearly test content and won't accidentally offend anyone.

When you are ready to go live, go through the user and content lists to remove anything that shouldn't be available. Also, browse through the entire site structure and look for menu links that shouldn't be appearing.

Sometimes, you won't have content for a section, but for layout or structure reasons it has to be in place. Make the text of the page say something like "Coming Soon" so it's apparent that the page is important, and get it resolved as soon after the live launch as possible.

If you are working with a code repository (like svn, git, etc.) you might have found it useful to set up a cron job that regularly runs a script that in turn triggers the update of your code on the server. While this is nice while developing it may be disastrous in production environment!

Make sure to disable any automated update of your code before going live.

fp