Administration Guide Getting started with Drupal 7 administration

Administration Guide
This guide provides information about the daily or ongoing operation of a Drupal site.
For information on developing the information architecture of a Drupal site, see the
Structure

Guide
. For information about adding features and creating the business logic of a site, see the
Site

Building Guide
.
Getting started with Drupal 7 administration
This section is an introduction to site administration for new Drupal 7 users. It covers the use of

administrator account and offers suggestions on where to start.
Understanding the administrator account
At the end of the installation process, the person who performed the installation is automatically

logged into the site with the administrator account. You may see the administrator account referred

to as User 1. This administrative account is automatically given all privileges for managing content

and administering the site. The best practice is to only give a developer or the highest level of site

admin access to this account. You can always grant users permissions by assigning them to certain

roles, so there is no reason to share this account.
Where to start
Here are some starting points for what you can do following installation:
1.
Check your site's status:
Navigate to the
Status report
page by going to
Reports > Status

report
through the administration toolbar at the top of the page to get an overview of your

site's current status. Items with a red background are issues that need immediate attention

(see
Reports
for more information). An example of this would be a required security update

for Drupal core or an installed module, or an unprotected settings.php file (see
What

permissions does Drupal need?
for more information). The Status report page may also

indicate that "Cron has not run," and give you an option for running it manually. Cron.php is

a script that needs to be run regularly for your site to continue functioning properly. See

Configuring cron jobs
for information on how to have your system automatically run the

cron script.
2.
Configure your site information:
You can change basic settings, such as the site name or

the default front-page path, by navigating to the Site Information page (
Administer >

Configuration > System: Site information
or

http://example.com/admin/config/system/site-information
).
3.
User management:
To add new users or manage existing users, to the
People
page

(
Administer > People
or
http://example.com/admin/people
. You can manage

user roles and permissions by clicking on the "Permissions" tab on this page. To change the

process by which users apply for accounts, visit the "People and Permissions" page

(
Administer > Configuration > People: Account settings
or

http://example.com/admin/config/people/accounts
). Please see the

Users, Roles and Permissions
page for more information on this topic.
4.
Add additional functionality:
Modules can be used to add extra features to Drupal. The

standard Drupal installation comes with a number of modules that are ready to be enabled.

In addition, you can download community-contributed modules to add even more features.

Navigate to the
Modules
page (
Administer > Modules
or

http://example.com/admin/modules
) to administer the modules that were

included. Additional modules can be found in the
Modules section
of Drupal.org. Please see

the
Installing contributed modules (Drupal 7)
page for more information on this topic.
5.
Customizing the site appearance:
You can change the site's appearance by installing new

themes or editing theme settings by navigating to the
Appearance
administration page

(
Administer > Appearance
or
http://example.com/admin/appearance
). Visit

Adding Modules and Themes
in the Drupal Cookbook for more information on how to add

themes, or take a look at the
Theming Guide
if you are interested in creating your own

custom theme.
6.
Posting content:
By default with a regular installation, Drupal 7 has two content types

enabled. "Articles" are generally used for posting frequently updated content (for example,

to the front page). The "Basic page" content type is generally used for creating the

equivalent of static pages (more permanent site pages). Navigate to the "Content"

administration page (
Administer > Content
or

http://example.com/admin/content
), then click the "Add new content" link to

add content to the site. You can also define your own content types by clicking the "Add

content type" link at the top of the Content types administration page (
Administer >

Structure > Content types
or
http://example.com/admin/structure/types
).

Visit the Drupal Cookbook page on
Creating content
for more details.
Below are additional articles on navigating specific aspects of Drupal 7's user interface.
Working with the toolbar
The administrative toolbar gives you quick access to the most important administrative pages. The

Toolbar module is enabled by default (unless you choose the "Minimal" profile when installing).

The shortcut bar that is displayed below it
Uses
Toolbar
The following links are available, given that their respective module(s) are enabled.
•
The home icon:
Return to the home page.
•
Dashboard:
Go to the administration dashboard.
•
Content:
Find, manage, and create new pages; manage comments.
•
Structure:
Edit blocks, define new content types, configure menus, administer tags with

taxonomy
, and configure some contributed modules.
•
Appearance:
Switch between themes, install themes, and update existing themes.
•
People:
Manage existing users, or create new user accounts.
•
Modules:
Update, enable, disable, and install new modules.
•
Configuration:
Configure the settings for various functionality, including some contributed

modules. You can edit user account settings, general site information, and settings for other

general administrative tasks.
•
Reports:
Display information about site security, necessary updates, and information on site

activity.
•
Help:
Display information about the functionality of all of the modules installed on the site,

including core modules. Each help page has a link to the module's online documentation

page on Drupal.org, where more information can be found.
•
User-specific actions:
Display the user account page or log out.
Shortcut bar
The grey bar below the Toolbar is a customizable list of
shortcuts
. Click "edit shortcuts" on the right

side to add to the default shortcuts. Or click on the down arrow next to "Log out" to hide the short-
cut bar.
You can customize different sets of shortcuts on the Shortcuts administration page (
Administer >

Configuration > User interface > Shortcuts
or

http://example.com/admin/config/user-interface/shortcut/
). Each set of

shortcuts is its own list of custom links, and each user can select which set they would like to see on

their user profile.
The shortcut set that is selected can also be displayed as a block in any region, by adding the

Shortcuts block to a region on the Blocks administration page (
Administer > Structure > Blocks
or

http://example.com/admin/structure/block
).
Roles and permissions
For the site administrator (User 1) and users with the "Use the administration toolbar" permission,

the toolbar is displayed at the top of the page.
Disabling
The Toolbar and Shortcuts bar can both be disabled by disabling their associated module via the

Modules administration page (
Administer > Modules
or

http://example.com/admin/modules
).
If the toolbar is disabled, you can reach the administrative screens directly by going to

http://example.com/admin
. Also, you can navigate to the Dashboard (which is at

http://example.com/admin/dashboard
and linked to in the default "Management"

block in the default Bartik theme) and then use the "By task" and "By module" tabs.
Working with contextual links
In Drupal 7, some modules supply contextual links that allow privileged users to quickly perform

tasks that are related to regions of the page without navigating to the Admin Dashboard. For

example, when you hover your mouse over a block or node, links are displayed that allow you to

make changes to the block or node.
Uses
You can enable and disable contextual links and you can specify the user roles that have permission

to view and use contextual links.
Enabling contextual links
To enable the Contextual links module:
1.
Navigate to the modules administration page (
Administer > Modules
).
2.
In the
Core
section of the
Modules
page, enable the
Contextual Links
module
3.
Click
Save Configuration
.
Configuring contextual links permissions
To set permissions for different user roles to access the contextual links:
1.
Navigate to the Permissions page (
People > Permissions tab
).
2.
For each role you can enable or disable the
Use contextual links
permission.
3.
Click
Save Permissions
.
Note that contextual links are not displayed if the user does not have permission to perform the

specific action represented by the link.
Adding new contextual links
This page contains a rough guide for adding new contextual links in a custom module of your own.
Contextual links are basically added in two steps:
1.
Declaring menu items using
hook_menu
or
hook_menu_alter
.
2.
Adding the contextual links render element to render arrays.
Declaring contextual link menu items
Contextual links are implemented as
local tasks
in the menu system. Additionally, the parameter

context
is set to
MENU_CONTEXT_INLINE
.
Menu items for contextual links could look like this:
<?php


// An example contextual link menu item.


$items
[
'contextual/%/information'
] = array(




'title'
=>
'Block information'
,




'type'
=>
MENU_LOCAL_ACTION
,




'context'
=>
MENU_CONTEXT_INLINE
,




'page callback'
=>
'contextual_example_page'
,




'page arguments'
=> array(
1
),




'access callback'
=>
TRUE
,

);


// To use local task menu items, there must be a parent page.


$items
[
'contextual'
] = array(




'title'
=>
'The contextual example page'
,




'page callback'
=>
'contextual_example_page'
,




'page arguments'
=> array(
1
),




'access callback'
=>
TRUE
,

);
?>
Adding the contextual link render element
The contextual link render element is added by using any function that can alter a renderable array.

An example follows:
<?php
/**
* Implements hook_block_view_alter().
*/
function
contextual_example_block_view_alter
(&
$data
,
$block
) {


// Contextual links can be added as a renderable element to the

content of

// a render array. We check if the block has content, and if so

add a

// contextual link to it.


if (isset(
$data
[
'content'
]) &&
is_array
(
$data
[
'content'
])) {




$contextual_links
= array(






'contextual'
,





array(
$block
->
module
),



);




$data
[
'content'
][
'#contextual_links'
][
'contextual_example'
] =

$contextual_links
;

}
}
?>
The contextual link render element has an array keyed with the module providing the contextual

links. This array has two values, the first being the path examined for local task menu items, the

second containing any callback arguments for that menu item (placed in yet another array).
Please note that this element
will be changed
by the contextual_preprocess function, moving it to

any title suffix element in that part of the render array. If there is no title suffix element, the

contextual links will not be displayed (unless you change the preprocessing).
Working with the dashboard
The dashboard gives administrators a customizable overview of important site information. You can

add and remove items from the dashboard, or you can disable the dashboard completely.
Displaying the dashboard
On the admin toolbar click
Dashboard
or navigate to

http://www.example.com/admin/dashboard
and you will see:
Adding, removing, or rearranging items in the dashboard
Click
Customize Dashboard
, and you will see a set of dashboard blocks that you can drag and drop

into and out of your personalized dashboard. Once dragged into the dashboard, you can also

rearrange each block into the desired position in the page. (The settings are saved automatically.)
The finished dashboard blocks will fill with information as the site is populated with content and

users.
Disabling the dashboard
1.
On the admin toolbar, navigate to the Modules administration page (
Administer > Modules

or
http://example.com/admin/modules
).
2.
In the Core section, disable the
Dashboard
module.
3.
Click "Save Configuration".
Working with the overlay
The administrative overlay makes it easier to administer a Drupal site by displaying administrative

pages as a layer over the current page (using JavaScript), rather than replacing the page in your

browser window. Once an overlay is active, you can use the close link on the overlay to return to

the page you were viewing before you clicked the link. In a "Standard" install, the Overlay module

is enabled by default.
Uses
Example
Administrative interface
without
the overlay:
Administrative interface
with
the overlay:
Accessing the overlay
When enabled, the overlay will appear when you click on administrative links. If you manually

enter a URL in your browser, overlay will not be used. To reset so that overlay is used again, leave

the admin section of your site, then return to the page on which you want to use overlay.
Roles and permissions
Users must have "access overlay" permission in order to see administrative pages in the overlay.
Disabling
1.
On the admin toolbar, click
Modules
.
2.
In the Core section, disable the
Overlay
module.
3.
Click
Save Configuration
.
How to alter the overlay
The following example shows how to modify the overlay when a specific node type (test) is

displayed inside the overlay. The script re-size the overlay to 450px wide and also hide some

unwanted items.
If you want to alter all the layouts no matter what, then
overlay.tpl.php
would be a better choice.
Declare your hook:
function mymodule_overlay_child_initialize() {

// Add our custom JavaScript.

drupal_add_js(drupal_get_path('module', 'mymodule') . '/overlay-
child.js');
}
Add the code to your JavaScript file:
(function ($) {

// Adjust the overlay dimensions.

Drupal.behaviors.myModule = {







attach: function (context) {





$('#overlay:not(.mymodule-adjusted)',

context).each(function() {







var $test = $(this).find('.node-type-test');















if ($test.length){









// adjust the overlay









$(this).css({











'width'




: '450px',











'min-width' : '450px'









});





















$('.add-or-remove-shortcuts', this).hide();

// hide

"add short-cut" button









$('#branding', this).hide();

// hide branding container







}







}).addClass('mymodule-adjusted');



}





};
})(jQuery);
Working with the shortcut bar
The Shortcut module provides a toolbar on the top of the page to which you can add links. This is

useful for creating links to commonly-used pages within your site. You can organize these links in

multiple sets of shortcuts.
Uses
Managing shortcuts
By default, two links are available in your shortcut toolbar: "Add content" and "Find content". To

add and edit shortcuts click the "Edit shortcuts" link in the toolbar.
The core Seven administration theme displays a + sign next to the page title which allows you to

create a shortcut to that page. (With the overlay module active, the page title appears above the

overlay, not under the breadcrumbs as you see here.) If the page is already part of your shortcut set,

the link will be a - sign, to remove the shortcut.
Once you've added it, you'll see the new link in your shortcut bar:
To manage shortcuts, you must have the
Administer shortcuts
permission.
Managing shortcut sets
You can organize shortcuts in sets. To add or edit shortcut sets, navigate to your account page

(
http://www.example.com/user
) and click the "Shortcuts" tab. Only one shortcut set can

be displayed at one time.
Displaying and hiding shortcuts
The core
Toolbar
module displays the shortcuts near the top of the page, along with an Edit

shortcuts link. The shortcuts can be quickly hidden by clicking the arrow sign in the toolbar.
You can display the shortcuts somewhere else in your site by enabling the Shortcuts block on the

Blocks administration page (
Administer > Structure > Blocks
).
Disabling Shortcut module
You can also disable the shortcut feature completely by disabling the module on the modules

administration page (
Administer > Modules
).
Getting started with Drupal 6 administration
When the install script succeeds, you will be directed to the "Welcome" page, and you will be

logged in as the administrator already. Proceed with the initial configuration steps suggested on the

"Welcome" page.
The "Welcome to your new Drupal website! page" outlines, in brief, with links, the basic steps to

setup and start using your Drupal site. Take a moment to review them.
These are the basic steps to setup and configure your Drupal site. This message will stay on your

front page until you promote something to it (default behavior) or change the front page setting.
At this time you have one configured account on your site. This account will always have access to

your entire site so do not share its password. Later, when testing regular account access, you should

use a different account.
Go ahead and select the administer link in the menu. This takes you to the /admin page. This is the

administrative starting page for your Drupal site. What you see here will largely depend on what

modules you have enabled. If a module is not enabled, you will not have an entry for it.
By default this page is task based and divided into five administrative areas.

Content management

- Manage your site's content. Most anything to do with content itself

will be here.

Site building

- Control how your site looks and feels. Here you make structure changes to

your sites look and feel.

Site configuration

- Adjust basic site configuration options. Adjust and configure site

behavior, name, email settings, cache, date and time, etc.

User Management

- Manage your site's users, groups and access to your site features. Here

you can manage accounts, users, roles and default registration requirements.

Reports
- View reports from system logs and other status information. Various logs and

information on your site are located here.
So, if by default the view is task based, take a look near the top and select
By module
. This will give

you a quick link view to various modules configuration settings and help. Once you are more

familiar with what you want to do on your site, this can be a quick way to get to the desired menus.

After a review, go back to the "By task" view.
Notes
•
A new install will have the message "Cron has not run. Please visit the status report for more

information.". Please make sure to
set up cron.
Running cron.php on a regular basis

performs basic maintenance and helps keep your site healthy.
•
If you haven't enabled the clean URLs option for your site, adding a /?q=admin/ after your

website domain address will direct you to your admin area.
For example:
MyWebsite.com/?q=admin/
•
If the default Drupal theme is not displaying properly and links on the page result in "Page

Not Found" errors, try manually setting the $base_url variable in the settings.php file if not

already set. It's currently known that servers running FastCGI can run into problems if the

$base_url variable is left commented out (see
http://bugs.php.net/bug.php?id=19656
).
Site configuration in Drupal 6
Go to Site Configuration (
Administer > Site Configuration
). Most options here are pretty self

explanatory, but a few important ones to consider are:
•
Error reporting
By default all errors are output to the log and screen. When your site is ready for production

you should change this to just write errors to the log only.
•
Input formats
Input formats are incredibly powerful and often missed configuration step early on. The

default for most user accounts is Filtered HTML. This is a list of tags allowed by normal

users to use on your site. There is a very minimal default selection which you can change.
<a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>

•
Performance
During development, caching should be disabled (default). Once the site is ready for

production you should set caching to normal. Experiment with these settings to find what

works best for your site.
•
Site information
In addition to Site name, which was set during install, you can also add a slogan, mission,

and footer. Other options include setting a name for anonymous users and changing the

default front page setting.
•
Site maintenance
If you need to take your site offline for any reason, here you can do this and set a message as

well. It is useful to know
how to log in once you have turned your site off-line for

maintenance
.
Specify 403 and 404 error pages
Drupal's page error messages are meant to be direct and to the point. If you want page error

messages that are a little more user-friendly, Drupal allows you to customize them.
1.
Create two nodes, one for each kind of page error (403 and 404).
2.
Determine the ID number of the node you wish to redirect users to. One way to determine

the node's ID number is to visit the node and look at the number after the last slash in your

browser's address bar. This is your node's ID number.
3.
Now enter the paths to your nodes in the appropriate boxes on your error reporting settings

page (mysite.com/admin/settings/error-reporting) For example, if the node ID number for

403 error codes is "83," you would type "node/83" into the "Default 403 (access denied)

page" setting.
Because you are creating nodes, they will show up in the tracker and popular content blocks and

anywhere else real nodes would be display. If this isn't acceptable, there is a contributed module

called
Custom Error
that avoids this problem.
Configure how users can input content
Drupal "input filters" are a little known but powerful feature. They can give a site administrator a

lot of control over the input of their site.
Some contributed modules
add various filters here to

control content display and link behavior.
"
Filters
" process text - by adding special code, supporting formatting shortcuts, or even removing

unwanted content.
"
Input formats
" are
collections
of individual filters, put together to let you decide what does and

what doesn't happen to your text.
Input formats are usually set per role - so different types of user have more or less control over the

layout of their posts.
In the Administration area, select
Site Configuration > Input Formats
.
(
?q=admin/settings/filters
)
There you can choose what happens to text or HTML that users enter. It's recommended that most

users are limited to using "Filtered HTML", which is simple HTML with all the potentially

problem-causing tags taken out.
Filters are managed by the
filter.module
How filters and input formats work
System: cron and caching
The system module provides system-wide defaults for running jobs at particular times, storing

(caching) web pages to improve efficiency, and performing other essential tasks. The module also

keeps track of various preferences you give for how you want your system to behave.
Some of Drupal's modules require regularly scheduled actions. The statistics module periodically

cleans up logfiles. The aggregator module periodically updates feeds. In Drupal 6.x and earlier Ping

periodically notifies services of new content on your site. In Drupal 6.x and later Update module

checks for updates on the modules and themes used in your site. Search periodically indexes your

site's content. All of these services rely on cron.
Cron is not a part of Drupal 6.x and earlier. It's a scheduler that resides on your server and performs

tasks (called "cron jobs") at intervals, which you specify. The jobs can run weekly, daily, hourly, or

whatever you like. Drupal 7.x includes functionality to run cron from within Drupal itself but for

performance reasons it's recommended to use the server's cron when possible
What you want to do is schedule a "cron job" that has a browser on your server regularly visit your

"cron page." For instance, if your site were
www.example.com
your cron page would be

http://www.example.com/cron.php.
(This page is automatically set up for you when you install

Drupal.) This regular visit to your cron page will help keep your system running smoothly.
For a modest personal site to which you post now and then, you might set up such a cron job to run

once a day. For a more active site you'd likely want to run that job more often--perhaps every few

hours or every hour.
With Linux or Unix you can schedule your cron jobs by setting up what's called a "crontab." (You

might rely on helper programs like C-Panel to make setting up your cron jobs easier.)
For further guidance you can see Drupal's handbook page
configuring cron jobs
(or, if your server is

running Windows,
configuring Windows cron jobs
). Your hosting company may also help guide

you.
The system module's caching mechanism stores dynamically generated web pages in a cache--a

stockpile--and reuses them. The pages on your site, rather than being never-changing sets of text

and images, are all (or nearly all) likely to use elements pulled together "on the fly" from various

parts of your database. Such pages are said to be "dynamically generated."
By caching such pages, the system module keeps them ready to use again, instead of having to

create them again each time someone wants to view them. This way, displaying a page takes only

one database query instead of several. Queries take time and system power, so caching lightens the

load on your system and lets it respond more quickly.
Only pages requested by anonymous users are cached. To reduce server load and save bandwidth,

the system module stores and sends cached pages compressed.
You can
•
run your cron job manually at your site's cron page. You can find links to both your cron.php

and a cron inside Drupal in your Status report under Administer > Reports > Status Report
•
read about
configuring cron jobs
.
•
administer cache settings in Administer > Site configuration > Performance
File system settings
Drupal provides configuration settings to control whether, and how, users and administrators can

upload files for use by Drupal.
The setup page
for File system path or Directory and Download method can be accessed by going

to:
Administer > Site configuration > File system
system path:
http://example.com/admin/settings/file-system

The default Drupal
setting for the File system path is sites/default/files. When you run across a

text box in Drupal for specifying a directory to store files, generally the root is sites/default/files. It

is good to have all files going to the files directory or directories within the files directory. Having

your files in one place will make backups easier to accomplish.
The default Drupal
Temporary directory is /tmp. This is where uploaded files will be stored during

previews before saving.
The default Drupal
Download method is Public - files are available using HTTP directly.
Note:
Un-configured or improperly configured Drupal installations may display one or more error

messages at the top of the "File system settings" page, indicating that either the "Temporary

directory" or "File system path" directories do not exist and/or their permissions are not set

properly. Simply create these directories and set their permissions so that Drupal can write and read

from the directory.
Drupal creates
these directories for you in most cases. Generally you can create directories using

FTP(file transfer protocol) software such as Filezilla.
To create a directory, connect to your server with FTP, navigate to the location needed, right click,

choose 'create directory' and give it a name. To set permissions for the directory, right click the

directory and choose file permissions or properties.
If you are unsure
about where or how to create directories or how to change their permissions, the

best place to get help is in the Drupal forums. When posting in the Forum, please use a descriptive

title for the post..
Download method
Download settings are configured in
Administer > Site configuration > File system
There are two possible settings for download method:
Public
and
Private
.
Set to
Public
if you don't care if any user, even anonymous users, can download the files uploaded

by other users.
Set to
Private
if you wish to restrict the ability of some users to download files uploaded by other

users.
Please note that if you set your download method as private, you should set your "files" directory to

be outside the document root for your Drupal installation (i.e. not in

http://example.com/files
or
http://example.com/sites/all/files
). The

private download method also has performance implications which you may want to consider.
If you change your settings at a later date,
all download URLs will change
, therefore it's best to

plan ahead when you set your Drupal site up and think carefully about whether you'll need to

restrict file downloads. If that's the case we strongly recommend setting the file download method

to private when you first create your site to avoid broken links later on. If your download method is

set as private, all users will still be able to download files until you set otherwise.
Here are just a few contributed Drupal modules to help control file permissions,

project/private_upload
and
project/file_access
Setting private download method tutorial
In order to make a private download truly private, you need to move the files directory (usually

under sites/default/files) into a new place
outside the Drupal installation
. It should be in a place

the user can't access via browser.
This tutorial is written based on my Dreamhost shared account. It is assumed you have shell (SSH)

access to your host.
Here are the the steps:
1.
Install Drupal.
2.
Connect to your host via shell.
ssh USER@example.com

3.
Create the new file directory.
mkdir MY_FILES

4.
Set it's permissions to 700 (only owner can read, write and execute).
chmod -R 700 MY_FILES

5.
Set you domain permissions to 505 for increased security (owner and public can read and

execute).
chmod -R 505 example.com

6.
Let's get the path to your new file directory.
pwd MY_FILES

7.
Copy the response (should be /home/XXX).
8.
It's time to tell Drupal where the new file system is. In admin/settings/file-system change the

file path to what you copied before and the new file directory (e.g.

/home/XXX/MY_FILES).
9.
Do the same for the temp directory (e.g. /home/XXX/MY_FILES/tmp)
10.
Optional: If you already have files uploaded you can change their location with the

following SQL, although you should be very careful with such changes.
UPDATE files SET filepath=REPLACE(filepath,

'sites/default/files', '/home/XXX/MY_FILES')

Restrict specific folders from public download

(via .htaccess)
If you set "public" as the download method, you can still protect some of your folders by settings in

your .htaccess file, if you have mod_rewrite enabled.
For instance, if your files live in sites/default/files, and you want to protect everything in

sites/default/files/protected_download_dir, then you can add the following line to your central

.htaccess file:
RewriteRule ^sites\/default\/files\/(protected_download_dir\/.*)$

index.php?q=system/files/$1 [L,QSA]
The files in this folder (or, all files that match the regular expression) will not be served directly by

apache, but by a full drupal request using the file_download() callback. The routing for system/files

is defined in system_menu().
.htaccess troubleshooting
There are some pitfalls when writing the htaccess file: you need to write correct regex syntax, you

need to escape things like slashes ("\/") and dots ("\."), you need linebreaks between different rules,

you might need specific RewriteCond statements with each rule, you need the correct apache

configuration, etc.
If you have something to share about your htaccess configuration, please do so!
Access Checking for File Downloads
Modules can do access checking on files downloaded through file_download(), by implementing

hook_file_download().
For instance, the filefield module will do access checking for all files that you upload via filefield. It

will only give access to people who are allowed to see the node and the field the file belongs to.
In addition, you can look for modules that restrict file downloads based on the folder name or other

criteria.
Access Checking built-in with Filefield
The filefield module has access checking built-in. To make use of this, please
1.
Configure the filefield you want to protect. Use the filefield path module, to define where

the files for the filefield should be stored by default.
2.
Add a line to your .htaccess to protect this folder (see above).
3.
Use whatever modules to restrict node or field access.
Files Attached to Nodes
If you want to protect files uploaded with the core upload module, have a look at the
Private Upload

module
.
Folder-specific Permissions
As an alternative, you can restrict folder access based on the Drupal permission system, introducing

one permission per folder. Have a look at
•
http://www.drupalcoder.com/story/406-mixing-private-and-public-downloads...


•
The
private_download module
, which is an implementation of the article above.
Typical Slip-Through Candidates
If you want to protect your files, you should think of the following situations where a file might

remain unprotected:
•
Thumbnail images
(for instance, those generated with
imagecache
or imagefield) typically

live in a different directory than the original. If you want to protect these as well, you need

to add new rules to your .htaccess file. You might even have to install additional modules for

the access checking.
•
Import directories
. If you use an importer to add your files, it can happen that a copy of the

file is still in the import directory. Solution is to either manually clean up the import

directory (via FTP), or to protect it (using a .htaccess rule).
•
Orphan files
. Sometimes when you delete a node with a filefield, the file will still be there,

but it will no longer be associated with any filefield node. This can happen if your filesystem

permissions don't allow deleting files. As a consequence, filefield's access checking will no

longer apply to this file. You need to find (or code) a new module to protect these files, or

you have to clean up manually.
Path settings
File system path
By default, this is set to "files". We recommend leaving this setting alone.
Temporary directory
By default this is set to "/tmp" which is the temporary directory common in GNU/Linux

distributions. If you are using a Windows or other kind of server, we recommend setting it to "tmp"

(no slash). Drupal will automatically create the temporary directory as a subdirectoy of the "File

system path."
If it does not due to permissions or other configuration issue's, you can create the file manually.
Date and time settings
Drupal allows you to configure how dates and times are formatted and displayed

(admin/settings/date-time). When making the format settings, you should probably consider the

culture of your target audience. Below are suggested configurations for the "Default time zone" and

"Configurable time zones" options.
For sites where most users live in a small geographic region:
Set the "Default time zone" to the time zone of the region and disable configurable time zones.
For sites where most users live in a region that spans a few time zones:
Set the "Default time zone" to the time zone usually considered to be the "standard" time zone and

disable configurable time zones. For example, in the United States, you would set your site's time to

the timezone that corresponds to Eastern Standard Time (EST).
For sites where users are likely to be scattered across the globe:
Set the "Default time zone" to the time zone to GMT (+0000) and enable configurable time zones.
Securing your site
This section provides security configuration advice for site administrators and includes both "things

you should actively do" and "things you shouldn't do". The order of chapters is an attempt at

identifying the priority of the configuration based upon the likelihood that it will be helpful and the

potential benefit/harm of the configuration.
Site administrators should also sign up for the
security mailing list
. People interested in discussing

security should join
Best Practices in Security Group
.
There are a number of contributed modules which can help with security, not all of which are

documented in this handbook. Among those modules is the
Security Review
module which provides

an analysis of your security configuration.
Securing file permissions and ownership
The server file system should be configured so that the webserver (e.g. Apache) does not have

permission to edit or write the files which it then executes. That is, all of your files should be 'read

only' for the Apache process, and owned with write permissions by a separate user.
As a quick test to confirm whether your site is secure or not you can run the
Security Review

module.
Note that this whole article is about "defense in depth." Drupal can run quite safely with

permissions a little "looser" than they should be. But if an administrator account is compromised by

an attacker or an attacker gains the ability to execute arbitrary code then the configuration below

will limit their ability to further exploit your site.
Configuration examples
For example, on many systems the Apache process runs as a user called "www-data". This user

should be able to read all of the files in your Drupal directory either by group permissions or by

"other" permissions. It should not have write permissions to the code in your Drupal directory. If

you use features of Drupal which require the "files" directory, then give the www-data user the

permission to write files
only in that directory.
Following is an example file listing of a
safe configuration
showing two files in a site where

uploaded files are stored in the "files" directory. In order to see the file permissions set for your set-
up, go to the command line and type:
ls -al
.
drwxrwx---

7 www-data greg





4096 2008-01-18 11:02 files/
drwxr-x--- 32 greg




www-data

4096 2008-01-18 11:48 modules/
-rw-r-----

1 greg




www-data


873 2007-11-13 15:35 index.php
In the above example, the web server user has the ability to write in the files directory, any users in

the group "greg" can read and write the data as well, but other users are not allowed to interact with

that data. The "index.php" file (representative of all code files) can be edited by members of the

group "greg" and can be read by the www-data group (we assume the www-data user is in the

www-data group). No other users can read that file. This is a fairly secure method of configuring

your site. You generally don't want random users who have the ability to read files on your server to

see inside those files, hence the last three permissions are --- instead of r-x.
Below is an
insecure
setup:
NOTE: THIS IS AN INSECURE CONFIGURATION
drwxrwx---

7 www-data www-data

4096 2008-01-18 11:02 files/
drwxrwx--- 32 greg




www-data

4096 2008-05-16 11:48 modules/
-rw-rw-rw-

1 www-data www-data


873 2007-11-13 15:35 index.php
This configuration allows the www-data user to edit the index.php file (and since it is representative

of other files, we assume every file that makes up the Drupal site). This configuration is dangerous

for the reasons outlined below. If you are using a configuration like this, please change it

immediately to be more like the first version.
Quick lesson in permission's numeric equivalents
Special numbers mean less than "read write execute".
In general, special numbers like "4 means read, 2 means write, and 1 means execute" are less useful

than "r means read, w means write, and x means execute."
However, some folks/software need numbers so:
rwxrwx---
is also 770
The order represents user-group-other. More information on permissions can be found later in this

document.
How insecure permissions are a problem
If you allow your site to modify the files which form the code running your site, you make it much

easier for someone to take over your server.
Worst case scenario: a file upload tool in Drupal allows users to upload a file with any name and

any contents. This allows a user to upload a mail relay PHP script to your site, which they can place

wherever they want to turn your server into a machine to forward unsolicited commercial email.

This script could also be used to read every email address out of your database, or other personal

information.
Undesirable scenario: if the malicious user can upload a file with any name but not control the

contents, then they could easily upload a file which overwrites your index.php (or another critical

file) and breaks your site.
Undesirable scenario: if the code allows users to see the contents of files, attackers could see

information which might reveal potential attack vectors.
If you are a sysadmin
Note for hosted Drupal installations
It's important to notice that the owner of Drupal's root directories and files is the root user and group

is the group your apache is running on. For files and directories inside the sites directory the user

who is hosting the site on your server is their owner. The best way to do this is to delete the site's

directory and make it a symbolic link to /home or other path you use to store user's home

directories. That way, if you create user names that matches the user's site name, the given

permission will be ok. The only thing to be done is to change the directory group to the group your

apache is running on.
The apache permission is given through group permission and others have no access at all to any

files and directories on a Drupal installation. Don't give in any way permission to others, otherwise

if your system is hacked through a weak password of a given user, the hacker will access all files

and directories of all installed sites on your server not only the one invaded. Even a read only

permission must be avoided, remember that database user name and password for each site are

stored in settings.php. Worse, if you give write permission to others, the hacker WILL alter files to

damage your site or upload malicious scripts to your server.
Follow this guide exactly as it is to make your Drupal installation as more secure as possible. This

guide was tested and works. If something goes wrong with your installation, review the steps,

possibly you missed something. If it really doesn't work post a comment with your doubt, we will

fix this guide.
Linux servers
To set the permissions all at once you can issue these commands from the Drupal root directory. I'm

assuming that greg user is part of greg group and that greg is the site owner.
Make sure you run

the following commands from inside Drupal's root directory otherwise you will mess up all

your filesystem's permissions
.
[root@localhost]cd /path_to_drupal_installation
[root@localhost]chown -R greg:www-data .
[root@localhost]find . -type d -exec chmod u=rwx,g=rx,o= {} \;
[root@localhost]find . -type f -exec chmod u=rw,g=r,o= {} \;
The second command will give ownership recursively on Drupal's root directory for user greg and

www-data group. Don't do this if you are in a hosted installation. To the Drupal's root files and

directories the user root must be the owner, not greg.
The third command will find all directories and subdirectories on Drupal's root directory and

execute a chmod that will change the permissions to read, write and access for user greg, read only

and access to www-data group and none to others.
The fourth command will find all files inside Drupal's directories and execute a chmod that will

change the permissions to read, write for the user greg, read only for www-data group and none to

others
Now for the "files" directories the permissions are slightly different because it must have write

permission to the www-data group too:
[root@localhost]cd /path_to_drupal_installation/sites
[root@localhost]find . -type d -name files -exec chmod ug=rwx,o=

'{}' \;
[root@localhost]find . -name files -type d -exec find '{}' -type f

\; | while read FILE; do chmod ug=rw,o= "$FILE"; done
[root@localhost]find . -name files -type d -exec find '{}' -type d

\; | while read DIR; do chmod ug=rwx,o= "$DIR"; done
These commands will give read, write and access for user greg and for www-data group and none to

others for all "files" directories inside Drupal's "sites" subdirectory and will give read and write

permission for all files found inside each "files" subdirectories.
Remember that any newly installed module/theme or whatever addon must have its permissions

changed too, It's better to do this BEFORE installing it in its appropriate Drupal directory.
Addendum on chmod non numeric permission representation
Meaning of the signs:
"+" add a permission to the ones already assigned
"-" revoke a given permission maintaining the others already assigned
"=" ignores the already assigned permissions and gives the ones listed
"u" = user
"g" = group
"o" = others
"a" = everybody (user, group, others)
For files:
r = read
w = write
x = execute
For directories:
r = list (read directory contents)
w = write
x = can access the directory. Whoever has not an x for a directory can't make a cd to it.
Using chmod without numeric values makes it more human readable. Here some examples of how

to use it:
chmod
commands and results for a file with permissions rwxrwx--- (770)
chmod human
chmod numeric
resulting permission
ugo=rwx
777
rwxrwxrwx
u-wx
470
r--rwx---
o+r
774
rwxrwxr--
g-wx,o+r
744
rwxr--r--
u-w,g-wx,o+r
544
r-xr--r--
g=,o=r
704
rwx---r--
a-wx
440
r--r-----
Windows servers
By default, Apache runs in the built in SYSTEM account. So all you have to do is change the

permission in a way that only the SYSTEM account, the administrators group and the user greg

have access to the Drupal root directory, subdirectories and files (assuming greg is the site owner).
You should exclude all other users and groups from the ACL. For the SYSTEM account give read

only access to all Drupal directories, sudirectories and files except for the "files" directories which

require write permission. For the user greg give read, modify and write permissions. And for the

administrators group give complete access. Go to the Drupal root directory, right click on it, go to

properties and then security.
Make use of permission inheritance to make things easier for yourself. And remember that any

newly installed module/theme or addon must have its permissions changed too. It's better to do this

BEFORE installing it in its appropriate Drupal directory. For those who use permission inheritance

it's done automatically by Windows.
Script based on guidelines given above
If you need to fix permissions repeatedly then the following script will help you, it is based on the

guidelines given above and performs some checks before any modification to ensure it is not

applied on files/directories outside your drupal installation.
#!/bin/bash
path=${1%/}
user=${2}
group="www-data"
help="\nHelp: This script is used to fix permissions of a drupal

installation\nyou need to provide the following arguments:\n\t 1)

Path to your drupal installation\n\t 2) Username of the user that

you want to give files/directories ownership\nNote: \"www-data\"

(apache default) is assumed as the group the server is belonging

to, if this is different you need to modify it manually by editing

this script\n\nUsage: (sudo) bash ${0##*/} drupal_path

user_name\n"
if [ -z "${path}" ] || [ ! -d "${path}/sites" ] || [ ! -f "$
{path}/modules/system/system.module" ]; then
echo "Please provide a valid drupal path"
echo -e $help
exit
fi
if [ -z "${user}" ] || [ "`id -un ${user} 2> /dev/null`" != "$
{user}" ]; then
echo "Please provide a valid user"
echo -e $help
exit
fi
cd $path;
echo -e "Changing ownership of all contents of \"${path}\" :\n

user => \"${user}\" \t group => \"${group}\"\n"
chown -R ${user}:${group} .
echo "Changing permissions of all directories inside \"${path}\"

to \"750\"..."
find . -type d -exec chmod u=rwx,g=rx,o= {} \;
echo -e "Changing permissions of all files inside \"${path}\"

to \"640\"...\n"
find . -type f -exec chmod u=rw,g=r,o= {} \;
cd $path/sites;
echo "Changing permissions of \"files\" directories in \"$
{path}/sites\" to \"770\"..."
find . -type d -name files -exec chmod ug=rwx,o= '{}' \;
echo "Changing permissions of all files inside all \"files\"

directories in \"${path}/sites\" to \"660\"..."
find . -name files -type d -exec find '{}' -type f \; | while read

FILE; do chmod ug=rw,o= "$FILE"; done
echo "Changing permissions of all directories inside all \"files\"

directories in \"${path}/sites\" to \"770\"..."
find . -name files -type d -exec find '{}' -type d \; | while read

DIR; do chmod ug=rwx,o= "$DIR"; done
Copy the code above to a file, name it "fix-permissions.sh" and run it as follows:
sudo bash fix-permissions.sh your/drupal/path your_user_name
Note: The server group name is assumed "www-data", if it differs modify it in the script code
Enabling HTTP Secure (HTTPS)
HTTPS
is a protocol which encrypts HTTP requests (like the kind you just made to see this page)

and their responses. This ensures that if someone were able to compromise the network between

your computer and the server you are requesting from, they would not be able to listen in or tamper

with the communications.
When you visit a site via HTTPS the URL looks like this:
https://drupal.org/user/login
. When you

visit a site via plain (unencrypted) HTTP, it looks like this:
http://drupal.org/user/login
.
Why is it important to you (and when)
HTTPS is typically used in situations where a user would send sensitive information to a website

and interception of that information would be a problem. Commonly this means:
•
Credit cards
•
Sensitive cookies such as PHP session cookies
•
Passwords and Usernames
•
Identifiable information (Social Security number, State ID numbers, etc)
•
Confidential content
Especially in situations where you as the administrator are sending your Drupal password, or the

FTP password for your server, you should use HTTPS whenever possible to reduce the risk of

compromising your web site.
HTTPS can also prevent eavesdroppers from obtaining your authenticated session key, which is a

cookie sent from your browser with each request to the site, and using it to impersonate you. For

example, an attacker may gain administrative access to the site if you are a site administrator

accessing the site via HTTP rather than HTTPS. This is known as
session hijacking
and can be

accomplished with tools such as
Firesheep
.
Security is a balance. Serving HTTPS traffic costs more in resources than HTTP requests (both for

the server and web browser) and because of this you may wish to use mixed HTTP/HTTPS where

the site owner can decide which pages or users should user HTTPS.
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:
•
Apache instructions

.
•
Ubuntu instruction


•
MAMP instructions


•
WAMP instructions


•
EngineX (Nginx) instructions

Chances are, your webhost can do this for you if you are using shared or managed 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
443 Session
or
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. You can run the HTTP site from a

different server and simply deliver a plain text message telling your users to use HTTPS.
Enhancing security using contributed modules

This section provides information about the various contributed modules that enhance security.
Standard related module categories are Security, User Access, and Spam Prevention:
•
Security category


•
User access / authentication


•
Spam prevention modules


In addition, these handbook pages cover key security issues:
•
Secure communications

: Secure Pages and related modules provide encrypted

communications.
•
Session management

: Control session usability and behaviour: duration, expiration, number

of available sessions are examples of these control features.
•
Password management

: Enforce the complexity of a password, or control how many times a

wrong login could be introduced blocking an account.
•
Authentication improvements

: Enrich the features of the authentication mechanism with

more secure options.
•
Spam Control Modules


•
IP blacklisting modules


•
Privacy management

: You store data from your users, make sure this information is secure.
•
Legal issues helpers

: Various modules provide "terms and conditions" capabilities and other

legal helpers.
•
Detection and Prevention of Vulnerabilities


•
Miscellaneous Security-Related Modules


Access control
For information on access control modules, see
Access Control management
.
Disable the permissions interface using Secure

Permissions
Secure Permissions
disables the user interface for creating and assigning roles and permissions.
Secure Permissions is an advanced security module for Drupal 7. It disables the Roles and

Permissions editing screens and lets all user roles and permissions be handled through code. This

adds an extra layer of security, as the site's permission can no longer be misconfigured accidentally.
This module was inspired the security paradigm of the Plone platform. See, in particular,
'Problem

A2: Broken Access Control'
in the Plone documentation.
----
1. Use case
This module is designed for cases where you want control of Roles and
Permissions only in a development environment. When fully enabled, this module
will make it so that the live site cannot have its permissions modified, except
through code.
It may be sufficient for most users to simply enable this module on the live
site, and to disable it when it is no longer needed.
----
2. Installation
Before installing this module you should configure the site Roles and
Permissions as you see fit. After installing and configuring this module,
changes to these settings can only be made through code.
On installation this module will have two immediate effects:
1.
Permissions will no longer be editable through the user interface.
2.
Roles will no longer be editable through the user interface.
On many sites, this is sufficient. However, for advanced security, you
have several additonal options. See sections 3 and 4 for details.
The module will also add a permission to your site, 'Export permission
definitions'. This permissions should be given to trusted roles before you
continue.
Users with this permissions may configure this module and may export site
Roles and Permissions to code.
----
3. Exporting settings to code
Give your account the 'Export permission definitions' permission defined by the
module or log in as the Site Maintenance user.
Find the link under People and Permissions >> Secure Permissions
Click the Export Permissions tab. It should take you to a form with a large text
area, filled with PHP code.
Copy the code. Place it in a module file and rename the hooks according
to the name of the module. Typically, this will be something like:


custom_secure_permissions_roles()

custom_secure_permissions($role)
Save the code into your module file.
Now you are ready to configure the Secure Permissions module to run.
----
4. Configuring the module
For advanced features of this module, you must export your Roles and Permissions
to code. Since this cannot be done before the module is installed, the module
will not enforce its rules until you tell it to do so.
To activate the module, navigate to:
Administer > Configuration and Modules > People and Permissions > Secure
Permissions
Here, you can tell the Secure Permissions module how to behave. You have seven
options that can be set.
'Enable secure permissions'
Check to activate the module's advanced features.
When set, the module will rebuild Roles and Permissions every time that
a module is enabled or disabled. Checking this option means that all
site Roles and Permissions will be managed in code. Default is OFF.
'Reload default permissions on rebuild'
Check to have the module load Drupal's default permissions for the
anonymous user and authenticated user roles when permissions are
rebuilt. Default is OFF.
'Show permissions page'
Check to allow the Permissions page to be viewed by administrators.
Disabling this option will prevent users from seeing permission definitions
at all. Default is ON.
'Show roles page'
Check to allow the Roles page to be viewed by administrators.
Disabling this option will prevent users from seeing role definitions
at all. Default is ON.
'Display permissions updates'
Check to display messages when Secure Permissions reset site permissions.
Default is ON.
'Use administrative role'
Check to include an administrative role from the site.
The 'administrator' role ships with Drupal, and has all site permissions. If
you uncheck this option, this role will be deleted. Default is ON.
'Administrative role name'
Set to the name of the administrative role you wish to use.
If 'Use administrative role' is disabled, this value is not used.
Default is 'administrator'. Normally, you should not change this value.
NOTE: If using translations, this string should not be translated through this
setting.
----
5. API hooks
The module functions by using two API hooks, described below. To use these
functions you must place them in a custom module file and name them properly.
The export function will generate these hooks for you. The API is described here
for developers.
----
5.1 hook_secure_permissions_roles()
Defines the roles used by a site. These are keyed by the uniqueness of the role
name, since we cannot guarantee the role id used by various sites.
WARNING: If you do not implement this hook, the module will reset your site
roles to the roles that ship with Drupal's default install.
Note that the module implements this hook to ensure that the 'anonymous user'
and 'authenticated user' roles always exist.
If the 'Use administrative role' is set to TRUE, the module will also maintain
an administrative role that has all site permissions.
The hook returns a simple positional array of unique role names.
<?php


function
example_secure_permissions_roles
() {



return array(






'editor'
,






'producer'
,



);

}
?>
----
5.2 hook_secure_permissions($role)
Defines the permissions assigned to each role. Typically, you will implement all
permissions for your site in this hook.
This hook takes a $role string as an argument. You should respond with the
appropriate permissions grants for that role. You should only return grants
that are TRUE.
<?php
function
example_secure_permissions
(
$role
) {




$permissions
= array(






'anonymous user'
=> array(








'access content'
,








'use text format 1'
,





),






'authenticated user'
=> array(








'access comments'
,








'access content'
,








'post comments'
,








'post comments without approval'
,








'use text format 1'
,





),






'editor'
=> array(








'bypass node access'
,








'administer nodes'
,





),






'producer'
=> array(








'create page content'
,








'edit any page content'
,





),



);



if (isset(
$permissions
[
$role
])) {





return
$permissions
[
$role
];



}

}
?>
NOTE: The use of
isset()
is recommended here, since the hook will fire
once per role, and it is possible that your module will not reply in all cases.
NOTE: If configured to do so, the module will return the default permissions
defined by Drupal's installer. Disable the 'Reload default permissions on
rebuild' setting to disable this behavior.
----
6. Drupal 6 support
This module was written for Drupal 7. It was backported to Drupal 6 using
the
Permissions API
module.
Login Security module / Lacking features /

other modules & integration
Login Security module
improves the security options in the login operation of a Drupal site. By

default, Drupal introduces only basic access control denying IP access to the full content of the site.
With Login Security module, a site administrator may protect and restrict access by adding access

control features to the login forms (default login form in /user and the block called "login form

block"). Enabling this module, a site administrator may limit the number of invalid login attempts

before blocking an account, or denying access by IP address, temporarily or permanently. The site

administrator can also be notified about password and account guessing, brute-force login attempts

or just unexpected behaviour with the login operation.
Module feature list
Ongoing attack detection
The system is able to detect if a password-guessing or brute-force attack is being performed against

the Drupal login form. Using a threshold value, you may instruct the module to alert (using a

watchdog message, and optionally send an email) the administrator user when the number of invalid

login attempts reaches the threshold value, used to early react on unexpected login attempts.
Soft Protections
Soft protections don't disrupt site navigation, but may alter the way a login operation is performed.

This kind of feature will make the system more flexible when a suspicious behaviour appears in the

login form. Currently, the login form submission can be soft-protected with these two options:
•
Invalid login request time delay
: on any failed login, the form submission is delayed a base

time, hardening the bruteforce attack to the login form. Including a time delay in each

invalid submission, will reduce the number of login attempts a user or script can do. This

protection is temporary, and once the user or script stops doing form submissions, the

penalty delay time will be removed.
•
Increase invalid login delay
: The base time delay could be extended and increased as the

number of login attempts do. This way, additional attempts to guess the password will be

punished with longer a delay in each submission.
•
Invalidate login form submission
: when a user or script triggers this soft-block protection

flag due to a large number of attempts, the login form ceases to actually submit, and any

new login request from this IP address will fail. however, the rest of the site is still

completely accessible as a regular anonymous user for that host, being unable to login

temporarily.
Hard Protections
When there is evidence of hard account guessing operations, or when you need to block users

because of leak password guessing attempts, Hard Protections may help defeating the system. These

actions have permanent results, and can only be revoked by the site administrator.
•
Block account
: it is common to block an account after a number of failed login attemps.

Once this count is completed, the account name used in the invalid login operations is

blocked and user and admin are advised about this.
Note: the user with uid 1 cannot be

blocked
. (It is recommended not to use 'admin' or 'administrator' as the name for user 1 for

this reason.)
•
Block IP address
: on a number of failed attempts, a host may be added to the access control

list. This action will leave the host completely banned from the site.
Lacking features / other modules & integration
Please see:
Is Secure Login still being maintained?
Notifications
The module also provides some notifications for the administrator or regular users to understand

what is happening. All the messages could be customized with several placeholders provided by the

module. This is the list of the notification options:
•
Display last login timestamp
: each time a user does success in login, this message will

remember him when was the last time he logged in the site.
•
Display last access timestamp
: each time a user does success in login, this message will

remember him his last site access.
•
Notify the user about the number of remaining login attempts
: It's also possible to

advice the user about the attempts available prior to block the account.
•
Disable login failure error message
: selecting this option no error message will be shown

at all, so user will not be aware of unsuccessful login attempt, or blocked account messages

(this includes the Drupal's "Invalid username or password" message.
•
Send an email message to the admin about blocked accounts
: an email could also be sent

to the administrator (uid 1), each time an account is locked.
•
Send email message to the admin about suspicious login activity
: an email could also be

sent to the administrator (uid 1), whenever suspicious activity being detected in the login

form submissions. When a determined value (threshold) of invalid login attemps is reached,

the email is sent.
Installation
Go to the
Login Security module project page
, download and install as any other Drupal module.
Configuration
To configure the Login Security module, please read carefully the README.txt file included in the

package. Once you understand the different options you may go to "Administer" > "Site

Configuration" > "Login Security" (/admin/settings/login_security) and configure with your

prefered settings.
Overview of Node Access modules
Drupal's API contains a pretty good
description
of how node access works (developers should also

analyze the
node_access function
itself). There are many contributed node access control modules

for Drupal and you really should understand the basics of node access before installing and

configuring one. The API should suffice for developers but for the benefit of our many community

members who build sites without reading code, here is a translation and some basic rules of thumb:
•
In general, you don't want to use more than one node access module on your site.
There

are many node access modules to choose from: taxonomy access, nodeaccess, simple access,

workflow access, etc. We all tend to add lots of modules to our sites and to expect them to

play well together, but node access is an area where we need to be extra thoughtful.
•
Users with permission to 'administer nodes' are never restricted by node access modules.

Users who do not have permission to 'access content' will never gain access from a node

access module.
Only users who have 'access content' and not 'administer nodes' are

eligible for the wild world of node access module control.

•
If a user's role has permission to create or edit a content type, or to edit their own posts in

that content type, that ability will always be allowed regardless of your node access module's

configuration. Delete access is included in the 'edit' permission.
If you want to control

creating, editing, or deleting of your nodes with a node access module, be sure to not

give your users these permissions in the permissions table.

•
If your content type comes from an additional module (forum, event, etc.) other than cck, it

may have its own permissions to set. Giving a role these permissions will also supersede the

use of any node access module.
•
Node access modules always GRANT access and never restrict it.
(It is a whitelisting

rather a blacklisting system.)
If you use two node access modules and one grants access

while another does not, access is granted.
One exception is the
Module Grants
module

through which it
is
possible to combine access grants across multiple modules in a more

intuitive way. Without it the displayed behaviour may appear backwards from what most

people would assume and it's the reason why it is tricky to get involved with multiple node

access modules. It is possible to use multiple node access modules in harmony however if

for example they are applied to different content types or are giving out different grant types.

•
The four types of possible grants on a node are: view, update, create, and delete. You can use

Devel module's devel_node_access
to analyze a node's node access grants. (Doing so as a

non-developer is a good sign that you've gotten into trouble with your node access modules

and may need to follow the above advice!)
•
The node access table in the database can become confused if you have, for example, toyed

with multiple node access modules or come into contact with a deranged one. If you have

been involved with risky node access behaviors you should rebuild your permissions. You

can find this option at admin/content/node-settings which is the 'Post Settings' configuration

screen. It is rarely necessary.
Access modules
Security Modules
lists some access modules and
http://drupal.org/taxonomy/term/69
lists every

module with the security tag.
Generic modules
Nodeaccess
Users with the 'grant node permissions' permission will have a grant tab on node pages

which allows them to grant access to that node by user or role. Administrators can set

default access controls per content type, and also define which roles are available to

grant permissions to on the node grants tab.
Access control list modules
The ACL module, short for Access Control List, is an API for other modules to create

lists of users and give them access to nodes. It has no UI of its own and will not do

anything by itself; install this module only if some other module tells you to.
Content access
This module allows you to manage permissions for content types by role and author. It

allows you to specifiy custom view, edit and delete permissions for each content type.

Optionally you can enable per content access settings, so you can customize the access

for each content node.
Forum access
This module changes your forum administration page to allow you to set forums

private. You can control what user roles can view, edit, delete, and post to each forum.

You can also give each forum a list of users who have administrative access on that

forum (AKA moderators).
Image gallery access
This module changes your image gallery administration page to allow you to set image

galleries private. You can control what user roles can view, edit, delete and post to each

gallery. You can also give each gallery a list of users who have administrative access on

that gallery (AKA moderators).
CCK field based modules
Nodeaccess userreference
Allows you to configure a CCK user reference field so that the user whom is referenced

in a node is granted access to view the node. There are also options to give the user

access to edit or delete the node.
Nodeaccess Nodereference
Gives access to users if they have access to a referenced node. Checks view, update, and

delete grants.
Node access auto reference
Gives automatic access to users if they are referenced somehow to this node.
It's scanning automatically for references with unlimited deep path, so you don't need to

worry anymore how to configure your permissions correct, because it's checking for

references automatically.
Taxonomy based
Use these modules to control access based on those tags, vocabularies, and terms you already use, if

you use them.
Classification, taxonomy and tagging modules
lists modules to help you classify and

tag content.
Taxonomy Access Control
Access control for user roles based on taxonomy categories (vocabulary, terms).
Connect roles to terms. Useful if everyone has the right role. A good way to control a lot of people

when they slot easily into a few roles.
Taxonomy Access Control Lite
This module restricts access so that some users may view content that is hidden from others. A

simple scheme based on taxonomy, roles and users controls which content is hidden.
Take the Taxonomy Access Control role based access and add user based controls. Lets you assign

users to roles and give the roles access to nodes by term but then lets you give special access to

those annoying management types who refuse to wait while you create a new role. Also gives you a

quick way to let contractors and temps grab quick access to resources. You know the situation.
Hey

it is seven minutes before your contract runs out. Rearrange the CRM system to include images the

same as Facebook. I will give you access to the 398 nodes you have to change. Fix all the spelling

mistakes while you are at it.
Taxonomy access user
Taxonomy access with inheritance.
Modules that contain node access modules
Workflow
The workflow module allows the creation and assignment of arbitrary workflows to

Drupal node types. Workflows are made up of workflow states. For example, a

workflow with the states Draft, Review, and Published could be assigned to the Story

node type.
Organic Groups
Enable users to create and manage their own 'groups'. Each group can have subscribers,

and maintains a group home page where subscribers communicate amongst themselves.
Domain
The Domain Access project is a suite of modules that provide tools for running a group

of affiliated sites from one Drupal installation and a single shared database. The module

allows you to share users, content, and configurations across a group of sites such as:
Modules for use by other modules
Relativity access
This module enables access control based on (and so requires) the Node Relativity

module. It propagates the grants from a node to its descendants. You should use another

module like nodeaccess to provide the grant to the ancestors.
Ubercart node access
UC Node Access lets you attach Node access features to products in your Ubercart

store. These features allow customers who purchase the product to receive view access

to nodes on your site either indefinitely or for a limited time based on the feature's

settings. UC Node Access does not handle access grants itself but rather depends on

other modules to define handlers that integrate UC Node Access with the various node

access modules developed for Drupal.
User points node access
The Drupal userpoints nodeaccess module enables you to sell access to a single node for

a specific category and amount of userpoints.
Ecommerce Node Access Product
Provides 'Node Access' settings for product nodes, whereby users who purchase the

product are granted view access to content, which can be predefined either by category,

by node, or by view.
Modules that alter the menu to allow access to give edit access
These modules bypass the node access system and instead alter access of node/%/view, node/%/edit

and node/%/delete, so may have issues scaling.
Node access
Menu node edit
Allows node editing access based on menu relationships.
Secure Site: control access to your site
Secure Site allows site administrators to make a site or part of a site private. You can restrict access

to the site by role. This means the site will be inaccessible to search engines and other crawlers, but

you can still allow access to certain people.
You can also secure remote access to RSS feeds. You can keep content private and protected, but

still allow users to get notification of new content and other actions via RSS with news readers that

support
user:pass@example.com/node/feed
URLs, or have direct support for user name and

password settings. This is especially useful when paired with the Organic Groups module or other

node access systems.
You can
•
manage settings at
Administer >> Site configuration >> Secure Site
.
•
choose which roles can access secured pages at
Administer >> User management >>

Permissions
.
•
view screen shots, file issues, read about known bugs, and download the current version on

the
Secure Site project page
.
Secure Site settings
Secure Site provides three methods of authentication: HTTP basic, HTTP digest, and HTML form.

For more information on HTTP authentication, see