The minimum password length feature in Logintoboggan allows admins to set any minimum length, and adds a message advising the user of what the minimum password length is to the set/change password fieldset in the registration or profile edit form.
However, core (in D7 at least) enforces a minimum 6 character length, and displays messages to this effect. The display of these messages is handled in /modules/user/user.js where the minimum length it tests for is hardcoded at line 110.
This results in conflicting messages being displayed to the user (see screenshot).
Comments
Comment #1
hunmonk commentednot really sure what to do about this one -- we can hook_js_alter i suppose, but that seems like overkill. suggestions?
Comment #2
steveparks commentedI looked at whether it would be possible to override Drupal.behaviors.password in logintoboggan.js, and then call a different version of Drupal.evaluatePasswordStrength -- but then that would have overridden the majority of user.js anyway!
So yes, I think hook_js_alter is the only way to go on this, but I agree it seems like overkill - and may well create a maintenance problem going forward as we have to track the original.
The bigger question is, if core is now enforcing a minimum password length (even if that's not user customisable), then is there a need for logintoboggan to provide this functionality?
So the options as I seem them:
1. use hook_js_alter to substitute a custom logintoboggan_user.js
2. move the minimum password length feature from the main LT module and into a contrib module, and do (1)
3. remove this functionality from the d7 branch of LT
In the case of 3, we could offer a patch in the core issue queue to provide for user-customisable password lengths. Also, there is already a contrib module that offers this functionality: http://drupal.org/project/password_policy and they have been working on their D7 release: #985374: Drupal 7 Port
Comment #3
hunmonk commentedremoving this feature now that we have a stable release is not a good idea in my opinion. however, since core will not allow anything less than a 6 character password, we should adjust the feature to remove options less than 6. this would involve:
all that's left after this is a slight UI weirdness, which is livable -- we can even adjust our description if the value is higher than 6 to say something like "further password hardening has been enabled, your password must be at least X characters long."
we can deal with smoothing the rest of this out in 8.x where things are more flexible.
Comment #4
steveparks commentedHere's a first attempt at a patch for this.
Background:
It turns out that although core _recommends_ a minimum password length of 6, it doesn't enforce this. Logintoboggan's role is now to offer to enforce the default level of 6, or a higher number set by the admin - and to communicate this clearly to the user.
This patch:
1. Allows the admin to either stick with the default core policy of recommending a password length of 6, but not enforcing it; or adding enforcement to that minimum; or setting a higher minimum and enforcing that.
2. Communicates this to the user by overriding the default javascript password security helper on registration and change password screens
3. Communicates any _required_ length of password to the user in the instructions below the password fields on registration or password change
To achieve this the patch:
1. Leaves the default on the variable_get()'s at 0 - so that the core default behaviour can remain if so selected by the admin
2. An upgrade hook checks for any historic value of 1-5 and changes it to 6
3. Overrides modules/user/user.js to provide a customised password security helper
4. Adds help messages to the password fields on the relevant forms
5. changes the select element on the logintoboggan settings screen to remove lengths 1-5.
6. abstracts the functionality to communicate any password length requirements into a separate helper function
I feel the end result for the admin and user is the best possible - but maybe the code isn't the cleanest approach just yet. Guidance on refactoring welcome.
Comment #5
hunmonk commentedwhile i appreciate the effort to create the best admin/user experience possible, this approach does so at too high of a code maintenance cost. look at all that code in user.js that we would then have to track to keep it functioning the same as core's user.js in the case of changes/bugfixes. we're already suffering this kind of issue with the form submit handler in user registration, and the js code that does the auto checkbox'ing on the permissions page. with those our hand is forced, as major pieces of LT's functionality would be compromised otherwise.
however, i'm not willing to make this situation even worse just because of a potentially confusing user message -- i think it's helpful to keep in mind that this is core's limitation we're stuck with... ;) so to be clear, i will not commit any approach that includes taking over user.js -- we need to find a more maintainable way to solve this in an acceptable manner in 7.x, and look towards 8.x to help fix core's limitation here.
what are your thoughts on my suggested approach in #3?
Comment #6
Leeteq commentedDoes this already exist as an issue in the core issue queue as mentioned in #2, to get rid of that hardcoded value?
IMO that is the best way to move forward. We should not have such things hardcoded anywhere.
This issues should be postponed here while being fixed in core, then continued for LT.
Comment #7
puddyglum+1 to have this fixed!
Comment #8
stevecowie commentedHere's a patch for this tested against dev. It essentially does the steps described at #3 above:
change variable_set/get to 6 throughout
add an update hook function to set to 6
make 6 minimum value for admin form
alter text of message so that it explains some extra hardening has been applied.
Comment #9
puddyglumHere is a patch that does not set any minimum length from 0 to 6, but instead allows logintoboggan to alter the help text to match the length specified by logintoboggan.
This is what we were looking for, and it seems to address the core issue of this bug report.
Comment #10
scottalan commentedGuess I should have looked at the issue queue first...
The patch I'm using, just another take but basically the same.
Comment #11
scottalan commentedUpdate: It seems that
modules/user/user.jsneeds a fix, or rather it would be nice. Not sure they will go for this but I'm in the process of submitting a patch for theuser.module. Since there isn't an 8.x branch started for logintoboggan I'll post the patch here for the 7.x branch. Any feedback would be appreciated. I'll also include an updated patch for logintoboggan that will work if the D7 core patch is implemented.Comment #12
Leeteq commented@scottalan; is there a related issue filed against core to adjust user.js?
Comment #13
scottalan commentedI found several that had to do with "Password length" but each seemed to be for different reasons. I chose this one: https://drupal.org/node/1824800 as it was labeled simply 'Password length'.
Comment #14
stefan.r commentedRTBCing #9, we have been using this on dozens of sites for 2+ years without any issues
Comment #16
stevecowie commentedCommitted. I'll leave this issue open until hopefully @scottalan and @stefan.r can confirm it's working for them fine in the dev branch.
Comment #17
wuffers commentedJust applied dev branch on an affected site and can confirm the help text is now consistent with password length setting in module.
Comment #18
chellman commentedDev branch has solved the problem here is well.
Comment #19
stevecowie commented