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
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Commentaires 0
Connectez-vous pour poster un commentaire