Problem/Motivation

The cron hook for Password Policy has a comment that states it checks a user's roles against the roles configured for a given policy, but this check doesn't occur. As a consequence, each cron run will subject users to potential password expiration for users that do not have a role captured in a policy configuration, or users who have permission to bypass password policies.

There is also a lack of checking if the policy has 0 days configured for password expiration on a given policy. My understanding is that if 0 days is configured as the password reset period, then the user's password should never expire. Otherwise, the user's password will always be expired after each cron run if password expiration is configured for 0 days.

Proposed resolution

Add in a few checks to account for role membership for each given policy, and account for the 0 days configuration for password expiration. Update policy configuration form to clarify the impact of configuring 0 days as the expiration period.

Remaining tasks

None.

User interface changes

Added some clarifying text to the policy configuration form for password expiration, to indicate 0 days configuration means passwords never expire.

API changes

None

Data model changes

None

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mroycroft created an issue. See original summary.

mroycroft’s picture

mroycroft’s picture

mroycroft’s picture

Status: Active » Needs review
nick.james’s picture

I have reviewed the code and it looks good to me. Testing soon to come.

spydimarri’s picture

Status: Needs review » Reviewed & tested by the community

Tested the code and looks good.

mroycroft’s picture

Issue summary: View changes
nerdstein’s picture

Status: Reviewed & tested by the community » Fixed

This mostly looks good and thank you for working on this.

I had some comments:

if (empty(array_intersect($policy->getRoles(), $user->getRoles())) || $user->hasPermission('Bypass password policies'))

This permission check seems awkward here. Should we consider adding a new "Bypass password reset" permission and use that as the check? There is still some awkwardness with administrative roles that have all permissions. For instance - if users intentionally want administrative roles to be reset - this permission check would always return true. This awkward relationship is outlined here: https://www.drupal.org/node/2735943

I think it's prudent to get this patch merged and solve the permission weirdness in 2735943.

nerdstein’s picture

Status: Fixed » Needs work

Attempted to roll the patch and it fails. Can this please be re-rolled? I'll get it merged in then.

mroycroft’s picture

Thanks for reviewing this patch! I agree, the permission check is awkward, but hopefully once https://www.drupal.org/node/2735943 is addressed/fixed, we can make a more clear or meaningful permission and use that instead.

I'll re-roll the patch as soon as I can, shooting for end of the week at the latest.

mroycroft’s picture

Some autogenerated directory snuck in there. Removed that. Here's the real re-roll.

mroycroft’s picture

Status: Needs work » Needs review

Not sure if the status should be set to needs review, or reviewed and tested, since this is a re-roll. I'll play it safe and put it in needs review.

nerdstein’s picture

Thanks - can you test out https://www.drupal.org/node/2709935? Once that's good to go, that gets in and these patches come shortly thereafter :)

mroycroft’s picture

Sure, I'll take a look at it.

nerdstein’s picture

Status: Needs review » Needs work

Attempted to merge patch in #13 and it fails based on the commit pushed from 2709935. Can you please re-roll once more? My apologies.

mroycroft’s picture

Status: Needs work » Reviewed & tested by the community
mroycroft’s picture

Status: Reviewed & tested by the community » Needs review

Setting to needs review so that tests run. -- Nevermind, they're not passing right now.

mroycroft’s picture

nerdstein’s picture

Status: Needs review » Fixed

This looks good, I am merging.

Details:
Code review looks good.

Automated tests pass (for the base module).

PHPCS fails (but the issues have nothing to do with the submitted patch and have been cleaned up in the new patch for https://www.drupal.org/node/2774969):

FILE: ...les/contrib/password_policy/password_policy_characters/README.md
----------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------
6 | WARNING | Line exceeds 80 characters; contains 114 characters
----------------------------------------------------------------------

FILE: ...d_policy/password_policy_history/password_policy_history.install
----------------------------------------------------------------------
FOUND 7 ERRORS AND 1 WARNING AFFECTING 6 LINES
----------------------------------------------------------------------
1 | ERROR | [x] Missing file doc comment
6 | ERROR | [x] Missing function doc comment, only found file
| | comment
7 | ERROR | [x] No space found before comment text; expected "//
| | add current user passwords" but found "//add
| | current user passwords"
7 | ERROR | [x] Inline comments must start with a capital letter
7 | ERROR | [x] Inline comments must end in full-stops,
| | exclamation marks, colons, question marks, or
| | closing parentheses
9 | ERROR | [x] Namespaced classes/interfaces/traits should be
| | referenced with use statements
17 | WARNING | [x] A comma should follow the last multiline array
| | item. Found: )
61 | ERROR | [x] Expected 1 newline at end of file; 0 found
----------------------------------------------------------------------
PHPCBF CAN FIX THE 8 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

FILE: ...rd_policy/password_policy_history/password_policy_history.module
----------------------------------------------------------------------
FOUND 10 ERRORS AFFECTING 9 LINES
----------------------------------------------------------------------
1 | ERROR | [x] Missing file doc comment
4 | ERROR | [x] Function comment short description must start with
| | exactly one space
6 | ERROR | [x] Missing function doc comment, only found file
| | comment
11 | ERROR | [x] Function comment short description must start with
| | exactly one space
18 | ERROR | [x] Function comment short description must start with
| | exactly one space
18 | ERROR | [x] Doc comment short description must end with a full
| | stop
21 | ERROR | [x] Namespaced classes/interfaces/traits should be
| | referenced with use statements
22 | ERROR | [x] Expected 1 space after IF keyword; 0 found
38 | ERROR | [x] Function comment short description must start with
| | exactly one space
44 | ERROR | [x] Expected 1 newline at end of file; 0 found
----------------------------------------------------------------------
PHPCBF CAN FIX THE 10 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

FILE: ...odules/contrib/password_policy/password_policy_history/README.md
----------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------
4 | WARNING | Line exceeds 80 characters; contains 108 characters
----------------------------------------------------------------------

FILE: ...es/contrib/password_policy/src/Annotation/PasswordConstraint.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
47 | ERROR | Class property $error_message should use lowerCamel
| | naming without underscores
----------------------------------------------------------------------

Time: 1.05 secs; Memory: 13.25Mb

  • nerdstein committed 24a37e0 on 8.x-3.x authored by mroycroft
    Issue #2773647 by mroycroft: Password expiration missing role and other...
bmsomega’s picture

Is there any sign of this fix being rolled into a 3.0.0-alpha3 version?

nerdstein’s picture

Yes - we have one outstanding issue that will be rolled into the next alpha (and hopefully first beta) release

Status: Fixed » Closed (fixed)

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