Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hello,
The rules work in the user profile when then choose to change the password, but do not appear to work when creating a new account. Any thoughts? We have extended the signup form with additional fields, could this have broken the password rules hook somehow?
Thanks
Comment | File | Size | Author |
---|---|---|---|
#5 | 900822_use_authenticaed_rid.patch | 517 bytes | willieseabrook |
Comments
Comment #1
seancorrales CreditAttribution: seancorrales commentedI 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.
Comment #2
Alan D. CreditAttribution: Alan D. commentedMarking 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.
Comment #3
bsevere CreditAttribution: bsevere commentedI 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:
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.
Comment #4
Alan D. CreditAttribution: Alan D. commentedI 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
Comment #5
willieseabrook CreditAttribution: willieseabrook commentedThe 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.
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.
Comment #6
bsevere CreditAttribution: bsevere commentedOK. I think this does work better than what I suggested as it enforces a default policy on all users.
Comment #7
rjdjohnston CreditAttribution: rjdjohnston commentedAppears to be working on registration now. Thank you for the patch!
Comment #8
bricef CreditAttribution: bricef commented+1
Comment #9
bcmiller0 CreditAttribution: bcmiller0 commentedsubscribe
Comment #10
Matt V. CreditAttribution: Matt V. commentedThe patch in comment #5 above worked for me.
Comment #11
tomw CreditAttribution: tomw commentedThe solution / patch in #5 worked for me
Comment #12
EvanDonovan CreditAttribution: EvanDonovan commentedPatch works for me as well. Confirmed by multiple users. RTBC.
Comment #13
JStarcher CreditAttribution: JStarcher commentedPatch works great, thanks.
Anyone else notice that the 6.x-1.0 release had zero changes aside from the .info files? Very strange...
Comment #14
hoporr CreditAttribution: hoporr commentedSwitching 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.
Comment #15
millwardesque CreditAttribution: millwardesque commentedThe 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
Comment #16
lowrytech1 CreditAttribution: lowrytech1 commentedApologies 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!
Comment #17
erikwebb CreditAttribution: erikwebb commentedI 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?