User Access & Authentication

Automatically log in via IP address, range or wildcard.

This module allows users to login automatically via their IP (v4) address ranges or wildcards instead of having to enter a username and password - plus many other features.

News - May 2015

• Updated 7.x-3.x version with Field API integration.
• Better handling of IP address data.
• Upgrade path provided to migrate from old to new IP address info.

News - May 2012

• 2.0 is out! Thanks for the bug fixes, tweaks and love from Jim Kirkpatrick, JohnV and PeterX...
• The 6.x-1.x branch is now deprecated. When you upgrade to 6.x-2.x (and you should, it's much better!) the IP field you added to users via core the Profile module will be auto-imported into the new ip_login_users table, so if you're not using Profile module for anything else it can safely be disabled.

Features

• Integration with User Login page and block, with customisable text and labels
• 'Log in by IP' block with simple auto-login link for those who don't want to use the modified User Login block.
• Users with permission can log out and and back into another account.
• Can be set to auto-login (or not) only on certain pages, or when custom PHP returns TRUE.
• Optional destination address can be set when logged in by IP.
• Lists IP-enabled users on the admin page at 'Site configuration' -> 'IP Login'.
• IP address matching works on:
  • Normal single IPs, comma separated: 123.4.5.6 or 123.4.5.6, 234.5.6.7
  • IP ranges: 123.4.5.6-10 or 123.4-111.5.6
  • Wildcards: 123.4.5.* or 123.*.*.*
  • Any combination: 127.0.0.1, 123.4.5-66.*, 234.4-5.6-77.*
  • Coming soon: IPv6 and Subnet matching via CIDR notation.
• Will work with external caches like Varnish when IP Login is set to auto-login only on specific paths.

This module allows administrators to control node access based on permissions. In drupal access control is based on the permissions
granted to a role. However most of the access control modules are based on roles and not permissions.

This module is an add-on for the Bio module, it automatically adds taxonomy terms to the Bio node based on the Bio nodes owners role.

Why?

With the Bio node assigned taxonomy terms with the same names as the rolse of its owner, it opens up a number of opportunities :

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.

Currently integrated node access modules include:

• ACL + Content Access - adds the customer's user account to the ACL defined by Content Access and adds expiration information beside the names in the Grant view access fieldset of the Access control tab for nodes governed by Content Access.

The Domain User Default module is a submodule for the Domain Access module that provides methods for users (and unauthenticated site visitors using the Session API module) to select a default domain. The module can be configured to automatically redirect users to their default domain upon visiting another domain, or simply provide a message when they are on another domain.

This Module provides an "Address book" feature. It searches an LDAP server for records and allow people to view the returned set. My company use it as a Company Directory. It is badly in need of some good Documentation and like everything dealing with ldap it is really hard to setup and get working.

This tool requires the ldap_integration module. http://drupal.org/project/ldap_integration

Title Permissions creates a permission scheme to restrict the editing of node titles of selected content types to designated roles. This module only affects content types that require a title. So as to not interfere with node creation permissions, the module only affects editing nodes, not adding them.

Title Permissions will work with CCK created content types.

This module will prevent users under the age of 13 from logging in if their respective parent or guardian (P/G) have not "signed" their COPPA compliance form. If a users Date of Birth -- stored in their user profile -- cannot be determined, the user will not be allowed to login.

P/G to child relationships will be loaded into an internal {coppa} table. This table will track the Parent to Child relationships and monitor when COPPA compliance was first achieved.

Suggested setup;

This is an OpenID selector for Drupal. The inspiration for this project comes from www.idselector.com. The module is useful for OyenID consuming sites.

There are two ways of selecting a provider (see the image):