A CAPTCHA is a challenge-response test most often placed within web forms to determine whether the user is human. The purpose of CAPTCHA is to block form submissions by spambots, which are automated scripts that post spam content everywhere they can. The CAPTCHA module provides this feature to virtually any user facing web form on a Drupal site.
We do this our spare time, which is unfortunately almost nonexistent at the moment due to real life obligations. To give the CAPTCHA module the required level of maintenance, an extra co-maintainer would be welcome. If you're interested in helping with this very popular module, please contact me or open an issue in the CAPTCHA module issue tracker.
The LoginToboggan module offers several modifications of the Drupal login system in an external module by offering the following features and usability improvements:
What is Content Access?
Yet another content access module.
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.
- It comes with sensible defaults, so you need not configure anything and everything stays working
- It is as flexible as you want. It can work with per content type settings, per content node settings as well as with flexible Access Control Lists.
- It tries to reuse existing functionality instead of reimplementing it. So one can install the ACL module and set per user access control settings per content node.
Furthermore the module provides conditions and actions for workflow-ng / rules, which allows one to configure even rule-based access permissions.
- It optimizes the written content node grants, so that only the really necessary grants are written. This is important for the performance of your site.
- It takes access control as important as it is. E.g. the module has a bunch of simpletests to ensure everything is working right.
The Login Destination module allows you to customize the destination that a user is redirected to after logging in, registering to the site (7.x), using a one-time login link or logging out (7.x). The destination can be an internal page or an external URL. It is possible to specify certain conditions like referring pages or user roles and make the destination depend upon them. You may use PHP snippets to provide custom conditions and destinations. It is also possible to keep users on the currently visited page after logging in or out.
The masquerade module is designed as a tool for site designers and site administrators. It allows a user with the right permissions to switch users. While masquerading, a field is set on the $user object, and a menu item appears allowing the user to switch back. Watchdog entries are made any time a user masquerades or stops masquerading.
OAuth implements the OAuth standard for use with Drupal and acts as a support module for other modules that wish to use OAuth.
Version 3.x is an entirely new module, previously known as OAuth Common, that takes an extended approach to dealing with OAuth. Not compatible with older versions of the OAuth module.
The ACL module, short for Access Control Lists, 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.
We're aware of the following modules using ACL (let us know if you know of others):
The Override Node Options module allows permissions to be set to each field within the Authoring information and Publishing options field sets on the node form. It also allows selected field sets to be set as collapsed and / or collapsible.
- Download, unpack and place in sites/all/modules/
- Adjust access control in admin/user/permissions
- Adjust Fieldset options in admin/settings/override_node_options
Note: Autocomplete "Authored by" field only works if user has "Access user profiles" permission.
For those wanting to allow users to view unpublished nodes may find this module useful, http://drupal.org/project/view_unpublished.
Access control for user roles based on taxonomy categories (vocabulary, terms).
By default, Drupal allows only users with "administrer menu permission" to add, modify or delete menu items.
In case you want for instance to let certain users manage primary links or secondary links but not navigation menu, this module provides this functionality.
Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. 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.
The upshot is, this module allows you to do things like 'node 123 can be viewed by authenticated users and edited by admin users and joeuser'. As an added bonus, update and delete permissions are separated, so you can make sure users with edit permissions cannot accidentally delete pages.
The previous maintainer (chadcf) had released a dev version of nodeaccess for D7. Over the following months a number of bugs/issues were reported and as of May 7th, 2013, all bug reports in the issue queue have been addressed (where possible) and with that, version 7.x-1.0 has been released as a stable/recommended release for Drupal 7.
The CAPTCHA Pack module contains several CAPTCHA types for use with the CAPTCHA module. The CAPTCHA Pack module is meant to provide lightweight, yet effective alternatives for the traditional image CAPTCHA, which is undesirable in certain situation (e.g. bandwidth restrictions, cpu restrictions, accessibility constraints, etc).
Import users into Drupal or update existing users with data from a CSV file (comma separated file).
[x] I agree check box to the registration page.
This module provides a way to specify a certain level of password complexity (aka. "password hardening") for user passwords on a system by defining a password policy.
Redirect the HTTP 403 error page to the Drupal /user/login page with an optional message that reads:
"Access denied! You must login to view this page."
Also, the desired page is appended in the url query string so that, once login is successful, the user is taken directly where they were originally trying to go.
Using the excellent phpCAS library, we have created a small Drupal module to allow single sign-on with CAS.
Fostering a relationship of trust with your visitors is essential when you aim to collect personal information and provide a service with which they feel secure. With this familiar little feature added to your installation you will portray the message of making every effort to address your users' security concerns and put them at ease. It shows that you stop at nothing to go the extra mile and allow them the peace of mind, to access your site with confidence from anywhere in the world knowing that you have taken every precaution to ensure their identity is safe.
Did you know that the default Drupal behaviour is to remember your session for the extent of 3 weeks and 2 days. This entails that if a user abandons a workstation, closes the browser window, experiences a power failure or any other unforeseen circumstance where they refrain from logging out, that their session will stay active on the server. When, at a later stage, they or anyone else for that matter, returns to your site using the same browser within the session cookie lifetime they will automatically be logged in without being prompted for authentication credentials. Can you imagine the colossal risk this places on users accessing your service from public terminals or shared workstations, with no means to their disposal of securing themselves against this threat.
Remove "Request new password" link from block and user page.
This module is very useful for sandbox sites where test users can't change your own password and for third party authentication like LDAP.
Login warnings problem
If you are having problems with login warnings, please take a look at this issue:
This very light-weight module allows additional permissions to be created and managed through a administration form. It uses the menu access system to allow or dissalow access to it.
On the administration page a user is able to create a permission with name and path(s).
These permissions can then be assigned to roles on the permissions page.
This module provides authentication services and an API to perform actions against Facebook. This module allows users to login to Drupal through the service commonly known as "Facebook Connect". This module is built with simplicity and flexibility in mind, it provides login services (and does it well), and an API for performing any other actions you may want to write yourself to query against Facebook's APIs.
- One-click login through Facebook.
- Automatic import of user e-mail and profile information during initial login.
- Integration with Profile module to map Facebook data to Profile fields. (Drupal 6)
- Integration with Field module to map Facebook data to fields on users. (Drupal 7)
- A flexible and direct API for modules to get authenticated and query Facebook's APIs (plus extensive documentation).
- Extensive permission settings for Facebook data retrieval.
- The ability to de-authenticate or unlink a Facebook account from a Drupal account.
- Does not require any external libraries or downloads.
Manage which roles can view, edit, and/or delete nodes by content type (default) or on a per-node basis (overriding defaults on each node).
Also supports changing permissions using Actions.
Allow non-admin users on your site to create new users. The module automatically sends an invite email to new users with login information.
This module integrates with OG. This means that users can create new users in a particular group.
- U Create module circumvents 'administer user' permissions by introducing the 'ucreate' permission. All users with the 'ucreate' permission will be able to create users.
- U Create OG module circumvents OG's 'group administrator' paradigm by using the same 'ucreate' permission. All users with 'ucreate' permission will be able to create users in any group to which they belong.
This module is dedicated to Jeff Miccolis.
Secure Login module enables the user login and other forms to be submitted securely via HTTPS, thus preventing passwords and other private user data from being transmitted in clear text. Secure Login module locks down not just the user/login page but also any page containing the user login block (or other forms that you configure to be secured).
For Drupal 7, Secure Login module enforces secure authenticated session cookies, thus preventing session sidejacking. For previous versions of Drupal, PHP's session.cookie_secure flag must be enabled on the HTTPS site to enforce secure authenticated sessions.
A word about Drupal 7's
Secure Login is intended for sites that want to offer anonymous sessions via HTTP or HTTPS and authenticated sessions only via HTTPS. Anonymous insecure sessions are migrated to authenticated secure sessions upon login, with all session data intact. Secure Login is designed to work with Drupal 7's
$conf['https'] setting at its default value,
Notifies administrator (site_mail) of new user registrations. Starting with Version 1.2 you can now define both the address it goes to and the subject and messages emailed. Starting with 1.8 you can get emails when someone updates their profile as well. Starting with 1.11 you can use actual profile pieces not just a list of them all. Example if you have a profile_name you would insert in the template !profile_name and the value of profile_name will be inserted.
Version 1.2 has a bug in the profile code. Please upgrade to the latest version. When upgrading from 1.2. Please going into admin/settings/register_notify and reset to default.
I did an alpha release of the project it seems to be working fine but needs some testing before I will say it is ready for prime time. It continue support for Profile and OG but I need to add support for Profile2.
As with all contributed modules, when considering submitting an issue: