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
Comments
Comment #2
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedHere is the patch with the proposed fix.
Comment #3
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedRevised patch, the value magic method shouldn't have been used here.
Comment #4
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedComment #5
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedComment #6
nick.james CreditAttribution: nick.james at Workday, Inc. commentedI have reviewed the code and it looks good to me. Testing soon to come.
Comment #7
spydimarri CreditAttribution: spydimarri commentedTested the code and looks good.
Comment #8
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedComment #9
nerdsteinThis 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.
Comment #10
nerdsteinAttempted to roll the patch and it fails. Can this please be re-rolled? I'll get it merged in then.
Comment #11
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedThanks 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.
Comment #12
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedPatch has been re-rolled.
Comment #13
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedSome autogenerated directory snuck in there. Removed that. Here's the real re-roll.
Comment #14
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedNot 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.
Comment #15
nerdsteinThanks - 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 :)
Comment #16
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedSure, I'll take a look at it.
Comment #17
nerdsteinAttempted to merge patch in #13 and it fails based on the commit pushed from 2709935. Can you please re-roll once more? My apologies.
Comment #18
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedSure, no problem. Here is a re-roll of the patch.
Comment #19
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedComment #20
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedSetting to needs review so that tests run. -- Nevermind, they're not passing right now.
Comment #21
mroycroft CreditAttribution: mroycroft at Workday, Inc. commentedUpdated this patch to also use the magic method to get the field value on the cron hook, same as #2774969: Update password policy submodule tests.
Comment #22
nerdsteinThis 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):
Comment #24
bmsomega CreditAttribution: bmsomega commentedIs there any sign of this fix being rolled into a 3.0.0-alpha3 version?
Comment #25
nerdsteinYes - we have one outstanding issue that will be rolled into the next alpha (and hopefully first beta) release