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.

Comments

Alan D. created an issue. See original summary.

aohrvetpv’s picture

Status: Active » Needs review
StatusFileSize
new571 bytes

Thanks for the bug report and analysis. I think using PasswordPolicyItem::isActive() is a fine fix. We could add validation for the special_count_chars field 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.)

alan d.’s picture

I didn't realise the constraint extend PasswordPolicyItem lol.

In that case rtbtc from me (without testing :P)

  • AohRveTPV committed 91cbb78 on 7.x-2.x
    Issue #3051903 by AohRveTPV: Constraints showing when they shouldn't
    
aohrvetpv’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.