Closed (works as designed)
Project:
Password Policy
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
9 Apr 2018 at 11:28 UTC
Updated:
5 Jun 2018 at 10:49 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
david.hughesAttaching patch, I'm having issues with running the tests locally though (the test for the delay constraint seems to always fail on the latest branch for me but is fine on SimplyTest.me). Will try running the tests on simplytest.me with the patch.
Comment #3
david.hughesPatch is still erroring with the delay constraint - anyone have any ideas on what's causing it to timeout?Ignore comment, I was looking at the wrong tab...
Comment #4
david.hughesI'm realising now that my wrapper functions for testing don't actually work as expected so live calls to HIBP are made in SimpleTest execution - currently trying to work out our options.
Comment #5
david.hughesFixed tests, issue was that I had misread how tests were set up and thus assumed
password_policy_testwas enabled for every test scenario - after realising that I enabled it just for this test case.Patch rerolled & interdiff applied.
Comment #6
david.hughesComment #9
aohrvetpv commenteddavid.hughes, thanks very much for this contribution, but please see #2956554: Built Feature: Keyboard Patterns regarding adding new constraints to 7.x-1.x.
I think we need to create some page that links to contributed constraints that people can optionally add to their installation, rather than adding new constraints to the stable branch at this point.
Comment #10
david.hughesNot sure how I missed that but OK, that's no problem. My client is currently on the 1.x branch and we can investigate upgrading to 2.x (though upgrading from a stable branch to an alpha tag is a little unnerving). Will fix the patch above to solve the error with
[]vsarray()syntax & other minor issues and then take a look at the 2.x branch.Comment #11
david.hughesAdding likely my last patch for the 1.x branch for reasons discussed above. Will see if I can get this rerolled for 2.x branch.
Comment #12
aohrvetpv commentedYes, 2.x is not the recommended branch, but it has no known security problems. It is fine to just use 1.x and place your custom constraints in the constraints directory. That is what I do for some sites I maintain. Unless you don't want any custom code in your module directories for configuration management reasons, etc. If you update the module with Drush, you do have to remember to copy your custom constraints back into the constraints directory.
We could set up a page somewhere with links to contributed constraints (such as this one) which people could copy into their constraints directories. That way people can find the constraints they need but this project would not have to maintain every constraint someone might need.
Comment #13
david.hughesJust got a notification from the 8.x version of this issue and thought I should close off this issue. Future Googlers, the patch in #11 is the patch you'll want :)