Password rules not taken into effect on create new account

I just encountered the same issue myself; I am running a custom hook_form_alter() on the user_register form. I did a print of the $form and didn't see the validate or submit functions in the form array.

Update: I disabled my custom hook_form_alter and password policy still wasn't enforcing my password policy on user registration. Password policy works great when updating an existing user's password.

Marking this as critical, as without it, the module only does half the job it should! I have this requirement for a project this week, so I may summit a patch in the next day or two.

I have verified the issue and can think of a couple ways to address it.

First, the reason that a policy is not enforced on the registration is that the module does not allow you to enforce a policy on anonymous users. The 'roles' radio element of the policy form is populated using a call to the user_roles() function and setting the $membersonly parameter to TRUE. That parameter omits the anonymous role from the returned array.

The easiest way to fix this issue would be to allow policies to exist for anonymous users by changing line #225 of password_policy.admin.inc to:

    '#options' => user_roles(),

A workaround that may suffice while waiting for a fix. Use the 'force password change on first login' option. When a user is registered they will need to change their password and be subject to any policy assigned to the 'authenticated users' role. But be careful not to set the 'delay' on that policy. If set the new user will need to wait that many hours before they can log in.

I would have thought that this should use the hook_user() & $op = 'validate', to parse the rules for authenticated users to enforce their policy. This is the only role that is granted by core, and when any other rules are applied latter, further checks could be done.

just my 2c

The easiest way to fix this issue would be to allow policies to exist for anonymous users by changing line #225 of password_policy.admin.inc to:

This was the first solution I considered also, in the end I decided to instead change _password_policy_load_active_policy to checked the authenticated rid, instead of anon, if no roles supplied.

 function _password_policy_load_active_policy($roles) {
  static $cache = array();
  if (empty($roles)) {
    $roles = array(DRUPAL_AUTHENTICATED_RID);
  }
  $key = implode(',', $roles);

This makes more conceptual sense, as an anonymous user can't really have a password policy,
because they never have a password.

See attached patch for the change.

This is only an interim solution however, what really ought to happen in addition to this is checks on user registration submit to see what roles checkboxes are marked.

OK. I think this does work better than what I suggested as it enforces a default policy on all users.

+1

subscribe

The patch in comment #5 above worked for me.

The solution / patch in #5 worked for me

Patch works for me as well. Confirmed by multiple users. RTBC.

Patch works great, thanks.

Anyone else notice that the 6.x-1.0 release had zero changes aside from the .info files? Very strange...

Switching this bug over to the 6.x-1.0 release.
The patch never made it into the release and, sadly, is still there.

This is a critical bug and needs to be addressed by the maintainer.

The patch works.

The patch in #5 works, but the module doesn't work fully on the user-create form (see http://drupal.org/node/900822). That might be why the anonymous-user functionality wasn't included in the first place

Apologies for the hijack, but does anyone know if this fix in #5 is also workable in 7.x-1.0-beta 1? I really need this for security purposes on my site!

Any help is appreciated.

Edit: OOF! Open mouth insert foot. (I asked before testing.)

This issue does not exist in the D7 version listed above. The module handled anonymous user sign-up flawlessly.

Nice Work guys!

I see several RTBC and successes, so I'll go ahead and committed to 6.x-1.x-dev - http://drupalcode.org/project/password_policy.git/commit/189d197

@millwardesque - Can you explain your hesitations?