501 Modules match your search

Extend and customize Drupal functionality with contributed modules. If a module doesn't quite do what you want it to do, if you find a bug or have a suggestion, then join forces and help the module maintainer. Or, share your own by starting a new module.

Restrict Page IP

Provides administrator to restrict/allow access to pages based on user IPs.

* IPs can be an individual IP or range of Ips.
* Page url can have wild cards like 'blog/*'
* Restricted user IPs will be denied showing
custom error message (can be modified on module's configuration page)

Note : User 1 has been skipped from these restrictions.


GeoIP Role

GeoIP Role allows to attach countries to roles.

GeoIP Role allows to dynamically grant roles to the current user according to his IP address location.
It depends on the GeoIP API module.

Currently, GeoIP Role allows to attach countries to roles, thus defining geographical zones.
When a user visits your site, he dynamically gain the role(s) attached to the country reported by his IP address.

GeoIP Role may be used with any other module like Nodeaccess that controls access based on user roles.


Conditional Roles

After much consideration, I've decided to scrap this module and take the project in a different (and, I hope, far better) direction as Access Control Kit. No further development will be done on Conditional Roles, other than to provide a migration path to ACK.


Pirobox Limit

Example of use Pirobox Limit

The Pirobox Limit module extends the Pirobox module with limiting and access functionalities.


  • Limiting the display of image groups.
  • Define a user role can see full image groups.
  • Configure a bypass to allow content owners to see full image groups.
  • Limits are configurable per content type and per Pirobox image field. In other words: per image group or respectively per gallery.
  • The limiting works also with multiple galleries for example on teaser pages.

The limiting-action is possible in 2 ways:

  1. Quietly
  2. Busily


  • Image groups are limited and no other actions.

It is possible to inform the visitor.

  • Display one, two or three limited images.
  • Use different image styles for the limited images in the content and the Pirobox.
    It is recommended to use the ImageCache Actions module.
  • Use an different Pirobox caption text for the limited images.
    The different caption text is configurable.

The quietly and busily settings are generally configurable for all limited galleries.

Required modules


URL token

URL token is an API module to make token-based access control simple.

There are two main features:

  • Request a token
  • Check that a token is valid (usually via a URL)

You should only install this module if another module requires it. This module doesn't provide any functionality by itself, it provides features for other developers to use in their modules.


Ctools Compare ID

Settings form

The module provides a ctools plugins to provide access control by checking for equality ID.

Supported entities for check access:

  • Node
  • User

An example of using the module:

  • Deny the display of the page to a particular user, if you know its identifier.
  • Overriding a specific page.


Restrict Abusive Words

Restrict Abusive Words

The Restrict Abusive Words module restrict to use words or phrases in forms all over the site content. The Restriction can be applied on content form, comment form, user profile form, user registration form and webform.Restriction can also be applied based on user roles.


Access Private

This module allow accessing private nodes with a direct link.


Domain ip

Domain_ip local tab

We recently saw a scenario where the client wanted to create an ip whitelist for their intranet site. This site is the same installation as the client’s public site. It simply has a different domain and different content. The question was ‘How we can manage separate whitelists and blacklists (ie ‘list sets’) for each domain, rather than one list set per installation.’

This module solves that issue. It is functionally a combination of two existing modules: ‘Ip_ranges’ ( http://drupal.org/project/ip_ranges ) and ‘domain_access’ (http://drupal.org/project/domain).
Domain_ip depends on Domain Access.

Domain_ip behaves similarly to ip_ranges, but it differs in the following ways:

  • Ip_ranges is used to define an ip whitelist and blacklist for a specific site. This is okay except for installations that also use the domain_access module, because they have different domains for a same installation. In this case, they are restricted to single list sets across domains. Whereas ip_ranges works against all domains for an installation, domain_ip provides a separate list set for each domain, respectively, meaning each domain has its own independent whitelist and blacklist.
  • To manage multiple sites, on the administration page there is a separate ip settings tab for each list set. Each domain has its own administration tab.


Iron Curtain

Developed by Reload, sponsored by Scribo.

This module allows the site admins to restrict access to certain paths or the entire site, based on the visitor's IP address.

It allows users with a certain role to bypass the system, it allows a list of paths to bypass the system and it allows you to make a list of paths which can only be seen by whitelisted IPs, and another list which can not be accessed by blacklisted IPs.


Le Gate- A generalized age gate solution

Le Gate is a simple module that restricts user access to pages on a site, and then provides two mechanisms
by which users can then gain access. It was first developed as an "age gate" module to allow access to a site
only when an appropriate age is selected (>15yo for COPPA). But then we decided to make it more generic.

When a user tries to access a restricted page they are redirected to a configurable and themable page
(the "le-gate" page) that presents one of two ways to gain access. When access is gained a javascript cookie is set.


Anonymous unpublished nope

Returns a 404 status when a anonymous user tries to access unpublished content.



The Mode module is a utility module that allows administrators to manage different permission sets and switch between them conveniently. It works by manipulating the permissions table during each switch.

Example scenarios where this module will prove useful:


Workbench Access Content Type

Extensible editorial access for the Workbench suite for granular access permissions by content types.

This module will add a new tab "Content Types" at the configuration page of Workbench Access, to provide permission by Section by Content Type.

This module was developed by Vardot for Georgetown University in Qatar.



Webform Per Email

Attaching to a webform


This module implements a permit based access system to allow anonymous users submit a Webform only if they display a valid one-time access permit.


File access by node type

File access by node type allows website administrators to select which roles can access files belonging to nodes of a certain node type. This goes beyond simple field permission, since there can be situations where users might embed an uploaded file into a Body textarea, or a WYSIWYG editor.

This module allows the restriction to work even in those cases by intercepting the file download before it happens. It also respects other access control mechanisms, since it defaults to either restricting access, or delegating it further. If the file download is not denied, and no other module is there to make a second decision, then it will download it. This allows for future integration with other modules and should be consistent in how Drupal handles access control.

To use

This module currently depends on FileField.

Enable this module as usual, then go to http://www.example.com/admin/settings/file_access_by_node_type to configure the different roles and node types.


This module was developed for Switchback by


Content Type Archive

This module allows you to "archive" content types by preventing new content from being created, but still allowing full access to existing nodes.


OG Announce

Extends the Organic Groups module to allow creation of announcement only groups, into which only group administrators may post.


Shared Access

The goal of this project is to provide a method for users to easily configure access settings to their own entities. The interface for configuring access will come from a shared access field attached to the entity.

Development Roadmap

  1. Implement field hooks to define the new shared_access field type.
  2. Define formatters and formatter settings.
  3. Define widgets.
  4. Implement an extendible access controller class structure for defining access realms and their underlying functionality.
  5. Define several default access realms (user, organic groups ... perhaps a few more).
  6. Implement field hooks so that a form shows up on the entity content page.
  7. Implement a standard sharing settings form that can hook into the access controller classes and be used to control access to the entity.
  8. Provide autocomplete functions and hooks for displaying user name/og suggestions as the user types
  9. Implement access hooks and query/query_HOOK alter functions to control access
  10. Implement field access hooks so that the form only shows when the owner or configured admins view the page.


Block Status

Screenshot of the block status administrative interface

This module adds a status-flag to blocks. Using this flag it is possible to specify whether a block should be published or not. Users with the appropriate permission may access unpublished blocks.


Restricted Home Link

This module provides a permission to prevent users from creating/editing/deleting/moving menu links pointing at <front>.

Use case: you wish to grant a user the ability to administer menu links, but you want a home menu link to always be the first link in the menu.


Read only node

The read only node module is allow you to set a node as read only by adding a new "Publishing option".
The module commes with 4 new permission :

  • set node as read only
  • set node stiky
  • set node status
  • set node promote

When a node is set as Read only, only the role with the permission 'set node as read only' can edit it.


GCC Hierarchy

This project allows to define group permissions (of GCC groups) for group hierarchies.

Supported hierarchies:
1. Core taxonomy hierarchies
2. Hierarchies created by Node hierarchy module

The patch from #2296515: Permissions in group hierarchies is required for GCC.


Node Relativity Access Control

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 content_access to provide the grant to the ancestors.

Just enable the module and select the content types that will inherit the grants at /admin/settings/relativity/access.


Services Content Lock


This module adds Services support to the community module called content_lock that will prevent two users from editing the same node concurrently. This module exposes the main operations of content_lock through Services as a resource, so that content locking can be done over a web service API such as REST for mobile applications or third party integrations. The main operations it currently implements are retrieve, create, and delete.


This module exposes the following operations of content_lock as a web service:

  • retrieve - Find out if a node is locked and get info about a lock e.g. who owns the lock and when it was created.
  • create - Create a new content lock on a node. Locks a node preventing other users from editing it.
  • delete - Deletes an existing lock on a node. Only the lock owner may delete the lock.


This module depends on the following modules: