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.
Shield Pages modules allows the administrator to secure any page in your website by password. You just need to go to configuration page of this module and add path, password. After that the added path will be password protected.
This module allow administrator to set global password for all shielded pages.This module allow administer to set multiple passwords for shielded page per path. This module provide bypass password protection of shielded pages permission also. All the shielded pages will be accessible by users having this permission.
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.
Nowadays bots are getting smarter and can use OCR tools to detect and bypass
captcha. Increasing the complexity of captcha usually makes it hard for users
to use it.
This module provides an alternative captcha security, where the user can use
a keypad to be to enter simple captcha numbers.
The keypad can be configured to shuffle the keys, improving difficulty of
automated bots to click on the right button.
Install the module as usual i.e. sites/all/modules
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.
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.
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.
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.’
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.
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.
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:
Simple OAuth is an implementation of the OAuth 2.0 Authorization Framework: Bearer Token specification.
Using OAuth 2.0 Bearer Token is very easy. See how you can get the basics working in less than a minute!
This project is focused in simplicity of use and flexibility. When deciding which project to use, also consider other projects like OAuth, an OAuth 1 implementation that doesn't rely on you having https in your production server.
This module grants per-session permissions for users to access nodes they created.
Yet another simple node access module, this time catering to users whose nodes have to be published for them to have access.
It grants temporary (session based) node access permissions to users with set
roles after they create that node.
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.
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.
Implement field hooks to define the new shared_access field type.
Define formatters and formatter settings.
Implement an extendible access controller class structure for defining access realms and their underlying functionality.
Define several default access realms (user, organic groups ... perhaps a few more).
Implement field hooks so that a form shows up on the entity content page.
Implement a standard sharing settings form that can hook into the access controller classes and be used to control access to the entity.
Provide autocomplete functions and hooks for displaying user name/og suggestions as the user types
Implement access hooks and query/query_HOOK alter functions to control access
Implement field access hooks so that the form only shows when the owner or configured admins view the page.