User access/authentication

Gigya Socialize provides a single API that aggregates authentication and social APIs from Facebook Connect, MySpace ID, Twitter, and OpenID webmail providers including Google, Yahoo, and AOL. The Gigya module for Drupal is fully configurable, requiring little time to install.

The Gigya Socialize module makes it easy for Drupal site owners to:

1. Authenticate users via Facebook, MySpace, Twitter and other OpenID providers enabling an increase in site registration rate by more than 30%.
2. Increase user acquisition by enabling users to invite friends to the site, or to share site content or a specific event.
3. Increase site traffic by sending user status updates, tweets and newsfeed events to social networks. Drupal site owners can couple user actions on the site with sending social network status updates, tweets, and publishing newsfeed items.
4. Customize the user experience by making it easy for sites to integrate user profile and social graph data
5. Easily configure the user experience, design, and module functionality using the Drupal administration panel.

Coworks is currently building a module to register and login on a Drupal environment with your eID card. We have still some hard developing work to do, so there is no release yet. We expect a dev release coming up in the next two weeks.

You can become more information on dieter@coworks.be.

This module unobtrusively adds additional checkboxes to the permissions form located at admin/user/permissions - the additional checkboxes provide a much friendlier interface for dealing with the hundreds of checkboxes that accumulate on the permissions page as roles and modules are added to a Drupal installation.

On a test Drupal site I set up with 6 user roles, 105 core and add-on modules enabled, 9 content types, and the content permissions module enabled, there were 138 distinct permissions and 828 individual checkboxes on the permissions page. To initially set up the permissions to something sane, it took me about 17 minutes. On my first attempt of using this module after fully developing it, after wiping and restoring the database from a back up, it took me around 5 minutes to set up the same permissions. The point is that this module will save you time, especially on large sites.

Allows domain administrators to make a domain open or closed.

Release 6.x-2.x
This release is to be used with domain_access 6.x-2.x.

Release 6.x-1.x
This release is to be used with domain_access 6.x-1.x.

Closed domain
Forces users to be assigned to a domain in order to view content on that domain.

Open domain
Anonymous users can view the content.

This an extension to the Domain Access module which is used to create many domains from a single installation.

Use case
Company website with one closed internal site(intranet) for employees and a normal open website for the public.

LCMS with multiple courses on different domains/subdomains. With domain_toggle some of the courses may be open and others may be closed.

Credits
The code used to close domains is copied from the domain_strict module, written by agentrickard.

Development is sponsored by Norwegian Centre for Telemedicine

This module provides dynamic [Log in/Create account][My account][Log out] menu links. Before the user is logged in, only the [Log in/Create account] link is shown. After the user is logged in, [My account][Log out] links are shown. By default, these links are in the "Account menu". However, they can be moved to any other menus through the admin/settings/accountmenu page to suite any menu structure.

These links are fully configurable through the admin/build/menu interface: they can be disabled, the link labels can be changed. They can be moved to any other menu using admin/settings/accountmenu and re-arranged to nested under another parent items using admin/build/menu. Note: whenever you move the links to another menu via the admin/settings/accountmenu page, configuration changes are lost. So first move to where you want the links to be, then set configuration.

The [Log in] link takes the user to the Drupal login screen and brings them back to the page from where they click the link.

The module handles access control of user login and registration by maintaining a list of masks, similar to the core user access features, but unlike the core it only triggers when a user is trying to authenticate or registering.

On most sites the purpose of banning a user is not to keep that person unable to access the content of the site, but to keep him, or her away from causing any harm with comments, posts, things in general that require signing in.

Drupal core in versions 5 and 6 uses a complete denial of access on a very early page load phase, which means that any core access rule is being run on every pageload, and the drupal_is_denied() call being an expensive one as it is (see more at #174025: Optimize query in drupal_is_denied: remove LOWER(), add indexes and #228594: UMN Usability: split access rules into an optional module), providing this alternative might be a good performance improving solution for large and busy sites.

Plans for Drupal 7

Once the module is stable and well tested I am going to port it to Drupal 6. The Drupal 7 version will be an upgrade path to the user_restrictions module.

The popups module is supported on the administration interface.

Development sponsored by Efero.