User Access & Authentication

Estonian national smartcard ID card login using http://openid.ee OpenID provider.

Installation

1. Download the module and copy to your module directory (most likely sites/all/modules)
2. Enable the module (note: it also enables openid.module)
3. Navigate to admin/build/block and enable "Estonian ID card login" block

Note: the new block is only visible to non-logged users. To test it, run another browser where you are not logged in to your Drupal site.

Usage

BOTCHA is a highly configurable non-CAPTCHA spam protection framework.

In CAPTCHA, user has to prove he/she is human. Unfortunately, spambots learned
to bypass CAPTCHA really well, and real users are frustrated with increasing
complexity and burden of CAPTCHA.

In BOTCHA, we don't abuse our human users - BOTCHA protection is completely
transparent to them and non-intrusive.

BOTCHA lets spambots to prove they are bots, and let real users zip by.

BOTCHA is useful for any form that has to be protected from spambots.

BOTCHA always works as designed - guaranteed! All of BOTCHA recipes are covered by Selenium-tests and we have our own "TestSwarm" to do testing as often as possible: see #1894478: The latest Selenium-tests launches & reports for details.
You could be also interested in #1896760: BOTCHA success stories.

The User Role Summary module provides a block which gives a summary of each of the user roles which exist, and which when clicked go directly to the user admin page filtered for users of that role type.

For example, the block might contain something like the following:
- Administrator (1)
- Basic member (328)
- Full member (7251)
- On-hold user (114)
- Suspended user (504)

You will see that in brackets is the number of users who have that role.

OAuth2.0 implement the OAuth2.0 draft standard for use with Drupal and acts as a support module for other modules that wish to use OAuth2.0.

This project will mainly based on oauth2-php library, including both server-side and client-side implementation. Resource server can operate in "Proxy mode" which bypass all core OAuth2.0 logic to Authorization server.

Author

Prevents the password from being auto-populated by the browser on Password field of User/Edit form.

This is useful because if the browser fills in the Password field, but not the Confirm Password field, when submitted the form will display a message asking for the Confirm Password field to be filled in and won't save.

This module uses JQuery to remove the password from Password field after the browser adds it. We use JQuery as some browsers don't respect autocomplete=off, and also autocomplete=off is not valid markup.

GeoIP Redirect uses the GeoIP API to redirect a user from your site to a different one based on their country of origin. The primary use-case is that you have 2 different markets and want to ensure users are accessing the correct form of that material. Here is a typical workflow for this module:

• You configure module to redirect all UK page views to exampleUK.com
• User accesses exampleOther.com from the US, France, etc and is granted access to the site

BUT

Project summary

Create usernames based on a persons real name, and save those values as user fields.

Tommy Lee Jones → TLJones

The Realname registration module is a solution for forcing professional usernames that are based on a persons real name. The Username on the registration form is replaced with First name, Middle name (optional), and Last name fields created and provided by the site builder. The first name, middle name, and last name are preserved in the defined fields, where it is later tokenized for further use.

This is a proof-of-concept module. Don't use it on a production site. This is an API module, and it does very little by itself. You probably shouldn't install it unless another module tells you to do so.

The original purpose of the module was to create a user-level access system for all entities. The high-level goal was to make it easy for a module to get an answer to the question "does User A have access to view the comment with ID 37?" The low-level goal was to create a system that allows simple granting/revoking of access to perform certain actions on entities, and this system should work with minimal changes across the rest of the Drupal site. For example, if User A does not have access to view node 42, then that node should not appear in Views listings for that user.

However, the reason this module was written was to make it easier to build a system for user-controlled privacy settings. That architecture has gone down a different route, and the code in this repository currently doesn't reflect that effort and won't be continued. I may still end up putting the user privacy effort at this namespace, but it will look very different than what is here now.

Allows adding to/editing terms of/removing terms from vocabularies per role.

You have set up some vocabularies (with some terms) like Color (Red, Green, Blue) and Shape (Toroid, Cube, Sphere). Maybe you even have a vocabulary that controls who can view a specific node (with terms) like Access control (Editors, Colleagues, World). Here comes trouble: your precious editors want to add more Colors, or reorder the terms of the Shape vocabulary (probably they want to see Sphere before Cube, who knows,) and you do NOT want to grant your editors the administer taxonomy permission, as it grants too much power (and that implies too much sharing of responsibility). Without this permission they were NOT able to do the mentioned tricks: adding terms to a vocabulary but not to another, reordering/editing terms of a vocabulary but not another's, etc.

These problem of yours is the past--just download and install vppr.module, and set it up at Administration >> Site configuration >> Vocabulary permissions.

Let users register with a password on the registration form when verification mail is required.

By default, users can create accounts directly on the registration form, set their password and be immediately logged in, or they can create their account, wait for a verification e-mail, and then create their password. With this module, users are able to create their account along with their password and simply activate their account when receiving the verification email.

The variable module, mail editor and commerce checkout are supported in the D7 version and the module is now in use in some complex setups.

Supported / related modules Drupal 7:

• Rules
• Variable
• Commerce Checkout Redirect
• Registration Password Token
• Mail Editor
• Mail debugger
• Email registration

Status D8 version:
User registrationpassword is compatible with Drupal 8 core from 8.1.9 / 8.2.1 due to #2765437, it will not work (and can't) with any older version.

Please report your findings in the user_registrationpassword issue queue. The issue queue is also open for new feature requests while a release candidate (RC) has not been released, be bold! And obviously we could do with more people testing the module.