Recently on a discussion list for Drupal and libraries, someone expressed a need similar to a problem I had solved and I thought it was a good opportunity to share. Simply, lots of site administrators use Drupal user accounts to manage information about people but don't ever intend that those people will log into the site.
In my case, I depend heavily on the Messaging/Notifications framework to communicate with library patrons. It requires that the people I communicate with be Drupal users. In the other example, someone wanted to create profiles of college faculty and integrate the standard Drupal contact form.
But it can be embarrassing when those people-who-aren't-users try to log into your site, and it can be insecure when they succeed. To prevent these nice people from even accidentally discovering that hey had "accounts", I wrote a hack using hook_form_alter() to make the the password recovery form return invalid for users that had a certain role. In effect, Drupal pretends those accounts do not exist.
I have now expanded my hack into a module, "Secret Users". The module provides a settings form that lets the administrator choose which roles should be invalidated and what rules to apply.
I realize that simply blocking a user forces the password recovery form to return invalid, but I think there is a need to allow for more complicated logic. A person with a "potential customer" role might easily become a "customer" some day. In my case, library staff are usually (but not always) library patrons as well, and it is a lot easier to manage their permissions if I can assign those accounts both roles.
I hope someone besides me can make use of this module and provide suggestions for improvement.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | secret_users.tar_.gz | 2.2 KB | calebtr |
| #1 | secret_users.png | 128.29 KB | calebtr |
Comments
Comment #1
calebtr commentedHere is the module I described and a screen shot of the administrative settings page.
Comment #2
calebtr commentedFollowing instructions to set the status to 'needs review'.
Comment #3
avpadernoHello, and thanks for applying for a CVS account. I am adding the review tags, and some volunteers will review the code, pointing out what it needs to be changed.
Comment #4
avpadernot().It would be probably better to implement
hook_form_FORM_ID_alter().The code should probably get the values to check from
$element, as the following code does:Comment #5
avpadernoI am closing this issue due to lack of replies.
Comment #6
avpadernoPlease read the following links as this is very important information about CVS applications.