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.
The configuration option for username constraint is not taken in account when the constraints are tested, so the validation (both php and javascript) is always executed.
After some debug, the problem is that the configuration is simply not tested in the validation functions (see constraint_username.inc, functions password_policy_constraint_username_validate() and password_policy_constraint_username_js(), the $constraint parameter is never used...).
Comment | File | Size | Author |
---|---|---|---|
#8 | password_policy-username_constraint_always_tested-1226418-8.patch | 2.33 KB | erikwebb |
#5 | password_policy-username_constraint_always_tested-1226418-5.patch | 1.37 KB | erikwebb |
#1 | check_name_constraint-1226418-1.patch | 625 bytes | frankcarey |
Comments
Comment #1
frankcarey CreditAttribution: frankcarey commentedYeah, just needed to actually check if the contraint is true (or evaluates to true). This should work, but I don't have time to test it. It is patched against my other patch that provides the ability to check names of new users, so you will have to apply that first. See http://drupal.org/node/1226434#comment-4770124
Man, 3 patches for me to get this working :(
Comment #2
jgalletta CreditAttribution: jgalletta commentedYour patch works fine for the server side validation, but you forgot to also patch the javascript part :)
The same if with a return ''; if !$constraint in the js validation function should be fine.
Comment #3
jgalletta CreditAttribution: jgalletta commentedThe server side validation patch works fine for me, now need a patch for client-side validation.
Comment #4
erikwebb CreditAttribution: erikwebb commentedAgreed, the patch in #1 looks like a win for the server-side. Any attempts on the JS side?
Comment #5
erikwebb CreditAttribution: erikwebb commentedActually, I just tried to reproduce the problem and wasn't able to. I add a new policy, set username to '1', receive the error. Then erase the username value, then the error goes away.
I've attached a patch that should fix this problem, but I'm not really able to see what the problem is at the moment.
Comment #6
jgalletta CreditAttribution: jgalletta commentedWorks for me, I wrote the same code a while back and it's working on live site since this time.
Comment #8
erikwebb CreditAttribution: erikwebb commentedI introduced a bug with that patch actually. The test itself was also broken. Re-running the tests with a new patch.
Comment #9
erikwebb CreditAttribution: erikwebb commentedhttp://drupalcode.org/project/password_policy.git/commit/fd4557a