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
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | cron-password-policy-fix-2773647-21.patch | 3.28 KB | mroycroft |
Comments
Comment #2
mroycroft commentedHere is the patch with the proposed fix.
Comment #3
mroycroft commentedRevised patch, the value magic method shouldn't have been used here.
Comment #4
mroycroft commentedComment #5
mroycroft commentedComment #6
nick.james commentedI have reviewed the code and it looks good to me. Testing soon to come.
Comment #7
spydimarri commentedTested the code and looks good.
Comment #8
mroycroft 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 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 commentedPatch has been re-rolled.
Comment #13
mroycroft commentedSome autogenerated directory snuck in there. Removed that. Here's the real re-roll.
Comment #14
mroycroft 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 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 commentedSure, no problem. Here is a re-roll of the patch.
Comment #19
mroycroft commentedComment #20
mroycroft commentedSetting to needs review so that tests run. -- Nevermind, they're not passing right now.
Comment #21
mroycroft 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 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