Compusure Drupal development

For a Drupal 5.x equivalent to this module, see http://drupal.org/project/recognized_user
This module adopts the known (or recognised) user concept, like you see on websites like eBay and Amazon, where a user who has previously logged in to the site is remembered by a cookie. In the case of this module, the site administrator can optionally assign a role to known users, extending their permissions to do some things that are more than an anonymous user can do.
As an example, with a site I'm working on you have to login to download files. However, for "remembered" known users we don't want them to have to login just to get a file - that's annoying - so we'll create a 'known user' role, set it as the role for known users to receive (in admin/user/known-user-role) and allow it to download files. That means you don't have to login fully to download files, but you must have logged in at least once on that computer in the last 30 days.

This module allows organic group administrators to set some content types as "read-only". Read only types can't be posted by simple group members, but still can be posted by group managers and users with "administer nodes" permission. Wiki group types can't be set to read only.
This module has been developed by Koumbit.org and is sponsored by Isuma TV.

Simple module to keep your Drupal session alive until the user close his browsers window. This option can be very useful if the Drupal administrator has no access to the settings.php or the session's lifetime really have to be limited for the view time because of any security issue.
The module try to keep the session with periodical site downloads. This is done by jQuery AJAX requests by default or can fall back to an IFRAME solution if JavaScript is not available at the client side.
The only modifiable attribute of the module is the period which can be set in a millisecond granularity. (This value will be round to seconds if the IFRAME solution is used.)

User level granular permissions system structured by taxonomy categories and permissions.

Login One Time provides functions for emailing a one-time login link to a user.
The use case for this is where your users are terrible at life and can't figure out how to use a username and password - so they phone you requesting an email link to what they need. Stop laughing.
Usage:
print login_one_time_button($account);
This will create a button, that when pressed sends an email to the email address of that $account giving them a one-time login link.
If you would like them to start on a particular page, you can add an extra parameter $path like so:
print login_one_time_button($account, $path);
If you would like to skip the button and just call a function that sends the email straight away:
login_one_time_send_mail($account, $path);
Email template configurable at the user settings page.
This modules differs to One-time login links as it emails the links and does not require you to download a CSV of one-time links to manage yourself.

This module allows users to "join" a role just using a given password.
Site administrator can decide WHAT ROLE users should be able to join using a password, and WHAT USERS should be able to use this feature.
Users can join selected roles, if they know the correct password; they can then leave that role, also if they dont know the password.
At the moment working only with Drupal5

Bit of a placeholder for now.
This does not do real openid login authentication, but uses openid as an identifier to return authentication session id.
To secure this, use SSL for sites that call this service or run the service, and enable API keys.

Create quota module restricts content creation of users based on a quota.
A possible use case for this module is a site that allows users to register for free and to create a certain amount of content until they are asked to pay for the service.
This module has Rules module integration which extends the functionality.

Allows a node to generate a password for itself that users must enter into their profile to be able to see that node.
The idea is that someone who has access to the node anyway (e.g., because of their user role) will be shown the password which they can then give to somebody else in person.
Usage example:
You run a body corporate website and are obligated to provide fire safety reports to residents.
Create a node type representing 'property', and create nodes representing apartment buildings with the fire safety information.
Create a nodeaccess_password realm named 'resident'.
Use another node access module to give access to the property node to someone in a user role 'manager' access to see the property and it's passwords.
This manager gives the password in person to residents and owners along with instructions.
Residents and owners can now sign up to the website and enter the password into the profile to be given access to see the property page, and to see it listed in views.

Anonymous Publishing module allows users with registered role to publish a content in anonymous way if they prefer, meaning that their content won't be never associated publicly to their user name. It also allows users with anonymous role to publish content remaining anonymous and activating the publishing of the content through a link sent in a verification email.
The module is still in development.