I see that the constraint for special_count is shown even when disabled (0 or nothing set for special_count value).
Just looking at password_policy_password_element_alter().
Calls the messages:
foreach ($policies as $policy) {
$items = array_merge($items, $policy->messages());
}
Which blindly check the defaults against what is saved.
Issue is that if they changed the default value, this constraint is considered active. Like just one char in this string was enough.
`~!@#$%^&*()_+=-|}{"?:><,./;'\[]
Clearly something like PasswordPolicyItem::isActive() should be used here, but no idea of the internals. This one is inactive if either special_count or special_count_chars are empty, so PasswordPolicyItem::isActive() is a bit simplistic.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | password_policy-7.x-2.x-fix_constraint_messages_showing_when_shouldnt-3051903-2.patch | 571 bytes | aohrvetpv |
Comments
Comment #2
aohrvetpv commentedThanks for the bug report and analysis. I think using
PasswordPolicyItem::isActive()is a fine fix. We could add validation for thespecial_count_charsfield to prevent invalid values (empty) from being input, as a separate issue.Note:
I had to make a commit fixing an unrelated problem in order for this patch to work:
https://git.drupalcode.org/project/password_policy/commit/80b82b2
(The tests had obsolete keys for the username constraint and relied on the current logic of
PasswordPolicy::activeConstraints()to work.)Comment #3
alan d. commentedI didn't realise the constraint extend PasswordPolicyItem lol.
In that case rtbtc from me (without testing :P)
Comment #5
aohrvetpv commented