By goose2000 on

Hi,

I am trying to locate and disable the built-in password strength checker in Drupal 6. This will confuse my visitors, they do not understand if it is being enforced or not. Not necessary in my case.

I have no idea where to look, any ideas / directions much appreciated.

⋅ Categories: Drupal 6.x

Comments

Garrett Albright’s picture

Garrett Albright commented

It's in modules/user/user.js. Try adding a return(); right after line 7.

goose2000’s picture

goose2000 commented

Thanks a million Garrett!

I added the the return(); and all is quite on the sign-up front. What did that do? Just fire off the function before it had any substance, rest of code was ignored ?

Garrett Albright’s picture

Garrett Albright commented

Yes, pretty much. The return() function causes the function to cease execution and move on to whatever code is next, so all the other code in the function never executes.

I kind of told you to do something wrong, though… We should never hack core modules. If you do a proper update of your Drupal installation the next time a new version comes out, you'll have to re-do this "fix" as well. But for a quick ten-second hack that gets the desired results, that'll do the job.

coreyp_1’s picture

coreyp_1 commented

Why not open a feature request to have an admin option to disable this feature?

- Corey

goose2000’s picture

goose2000 commented

Oh, I'm well aware of this - don't mess with the core. This site will not run for long, six months maybe. For it's short life, I felt it ok and probably won't update it, as long as I think it's secure.

I would agree that a feature request go in. I'm just not clear why this went into core in 6? Now we need a feature to pull it out. When it was a module, you could pick and choose.

ardarvin’s picture

ardarvin commented

This is indeed confusing to the end user. I've hacked / disabled it. I wish there were an option to disable it.

pillarsdotnet’s picture

pillarsdotnet commented

See Programming: Never Hack Core and Site Building: Never Hack Core.

Good. — Fast. — Cheap.
(Pick any two.)

jim kirkpatrick’s picture

jim kirkpatrick commented

Using Garrett's idea as a base I wanted to see if I could disable password strength messages but not the client-side check to see if they match.

Simplest way I could see was to comment the two lines following this comment // Show the indicator and tips. (on line 87 in modules/user/user.js)

BUT, I already have my custom module adding some js to the user registration page. It'd be more 'Drupally' to add more js/jQuery to that so it would override/modify the existing Drupal.behaviors.password stuff rather than hack the core. Is there a js guru with any ideas??

Drupal consultant & senior developer - http://www.i-jk.co.uk/

Garrett Albright’s picture

Garrett Albright commented

I'm thinking it might be as simple as just replacing Drupal.behaviors.password with your own function. The trick would be making sure it's put into place after Drupal puts its one into place, so that Drupal's isn't actually overwriting your own. Maybe something like this?

$(document).ready(function() {
  Drupal.behaviors.password = function(context) {
    …your own function…
  }
});

…and then

<?php
// Set the defer attribute
drupal_add_js('path/to/my.js', 'module', 'footer', TRUE);
?>

Failing that, you could use jQuery's unbind() to remove Drupal's keyup event watchers from the password fields (which it binds on lines 111 and 112 of user.js) and then bind your own.

Just a couple shots in the dark, though. Is there something insufficient about Drupal's implementation that's making you want to reinvent this wheel?

Anonymous’s picture

Anonymous (not verified) commented

Worked for me. I know it's bad taste to modify core, but I was getting so many complaints from people who didn't realize that the password strength suggestions were just that, suggestions. It still checks for password match, but only after you try to submit different passwords, which is fine by me.

ethosophical’s picture

ethosophical commented

subscribing

asak’s picture

asak commented

It's very nice to have a password strength check built into core - but i'm pretty sure this should be optional.

Subscribing.

rob5408’s picture

rob5408 commented

Hi there, the behavior in the js is set based on the input class of 'password-field'. I just decided to remove it in my preprocess function. What are the drawbacks of doing it this way? Besides having multiple classes and needing to pull out the exact one that causes the behavior to be attached (unsetting the class worked for me as I only had one).

function mytheme_preprocess_user_register(&$vars) {
unset($vars['form']['account']['pass']['pass1']['#attributes']['class']);
unset($vars['form']['account']['pass']['pass2']['#attributes']['class']);
}

It should be noted that the second unset is used to remove the behavior of making sure the passwords match.

meta4joel’s picture

meta4joel commented

Hey, I'm trying to remove this as well, but I really don't like hacking core. Anyone able to find a non-core-hacking solution for this yet? I removed the strength tips using CSS, but the warning box with "It is recommended to choose a password...." that shows in that horrid pink color still comes up and won't take my styles.

I implemented the line 7 hack for now, but would love a better solution if there is one.

Thanks so much!

Rosamunda’s picture

Rosamunda commented

+1

jraper@groups.drupal.org’s picture

jraper@groups.drupal.org commented

See http://drupal.org/project/disablepwstrength

terabitez’s picture

terabitez commented

Can't use this to disable just the "password description" (...It is recommended to choose a password... ).

DL Dunning’s picture

DL Dunning commented

I discovered that the password strength checker was broken on my site after I took it live. I was able to identify that the cause was enabling "Optimize JavaScript files" at admin/settings/performance. Enabled = broken checker. Disabled = working checker.

Is there somewhere more appropriate that I should report this? I'm running Drupal 6.12 on shared hosting.

jmar777’s picture

jmar777 commented

I think this probably warrants for a setting in the core module, but for a quick fix that doesn't require hacking the core, you can add this to your stylesheet:

.password-description {
    position: absolute;
    left: -9999px;
}

Kind of cheating and I wouldn't consider this "optimal", but it works if you're not willing to modify the core module (which I didn't want to do either...).

Zardoc’s picture

Zardoc commented

If you set the class to 'module-class-processed' in a hook_form_alter on the user registration form, the javascript will not check the password strength.

$form['account']['pass']['pass1']['#attributes']['class'] = 'module-class-processed';
$form['account']['pass']['pass2']['#attributes']['class'] = 'module-class-processed';

wilmar81’s picture

wilmar81 commented

I Just found another way to disable password checker.

I you look at the code inside user.js (modules/user/user.js), you will notice the events blur and keyup are bind to input.password-field and input.password-confirm.

Rather than hacking the core (which is really a bad habit, since you'll do it everytime you update drupal core), you can create a js file and put the following code inside:

Drupal.behaviors.unsetPasswordChecker = function(context) {
	$('input.password-field', context).unbind('keyup', Drupal.behaviors.password.passwordDelayedCheck);
	$('input.password-field', context).unbind('blur', Drupal.behaviors.password.passwordCheck);
	$('input.password-confirm', context).unbind('keyup', Drupal.behaviors.password.passwordDelayedCheck);
	$('input.password-confirm', context).unbind('blur', Drupal.behaviors.password.passwordCheck);
}

To load the file you can use a theme or a custom module.

We you decide to use a theme, just add the file in the scripts array in you [theme].info file. To know how, check this

But you can also write a small module (if you don't already own some) to load the file with drupal_add_js

<?php
  ...
  drupal_add_js(drupal_get_path('module', '[module_name]') . '/[path_to_js_file]');
  ...
?>

But there's a module which handles it easily: Password Strength Disabler.

Hope it helps.

sibopa’s picture

sibopa commented

I don't believe it's a good idea to disable user.js feature.
However, I was able to get around it with css, as I'm not that good in programming:
1. hidding the description box and messages
.password-description {
position: absolute;
left: -9999px;
}
this hides the box. you can also decide not to display it
div.password-description {display:none
}
At this point you still have the "password Stength:low" and the "password match:no match" messages, what I need for my project. I put "div" around this in the user.js file, and used css positioning to position it were I want.
2. but if you want to hide this too, do this:
span.password-strength, span.password-confirm {display:none}
at this point everything is hidden.
Hope this may help

webankit’s picture

webankit commented

I have installed Login Toboggan Module and I wish to modify tips to say
>required 8 Characters in Password Tips

AlonGoldberg’s picture

AlonGoldberg commented

and it works a treat without hacking core or installing more modules:

$('#edit-pass-pass1, #edit-pass-pass2').unbind('keyup').unbind('blur');

(assuming #edit-pass-pass1 + #edit-pass-pass2 are the ID values for both the password fields...)

Sepero’s picture

Sepero commented

I tried adding both of these to my theme's template.tpl.php file and cleared the cache. Neither seem to have any effect. (theme name is sky. using D6) Help?

function sky_preprocess_user_register(&$vars) {
  unset($vars['form']['account']['pass']['pass1']['#attributes']['class']);
  unset($vars['form']['account']['pass']['pass2']['#attributes']['class']);
}

function sky_user_register_form(&$form, &$form_state) {
  $form['account']['pass']['pass1']['#attributes']['class'] = 'module-class-processed';
  $form['account']['pass']['pass2']['#attributes']['class'] = 'module-class-processed';
}
Sepero’s picture

Sepero commented

In the function mytheme_theme(), create or add a function register for 'user_register' to the array, like this

function mytheme_theme(&$existing, $type, $theme, $path) {
  return array( 'user_register' => array('arguments' => array('form' => NULL),) );
}

And add this function

function mytheme_user_register($form) {
  unset($form['account']['pass']['pass1']['#attributes']['class']);
  unset($form['account']['pass']['pass2']['#attributes']['class']);
  return ''.drupal_render($form);
}

(be sure to clear your cache afterwards)

Sepero’s picture

Sepero commented

bump

hgneng’s picture

hgneng commented

drupal_add_css('div.password-strength, div.password-suggestions {
display:none !important;
}', 'inline');

Cameron Wong
http://www.eguidedog.net

bendikrb’s picture

bendikrb commented

Simply remove the process callback which attaches the javascript;

function yourmodule_element_info_alter(&$type) {
  array_pop($type['password_confirm']['#process']); // removes user_form_process_password_confirm
}
owenbush’s picture

owenbush commented

I know this is old, but I feel that some of the responses here are not following any sort of best practice. Modifying core js files is a recipe for a disaster - if you update core you'll lose your change.

The better way at least in Drupal 7 to achieve this is to do something like this. Create a module (I'll assume you know how to do that), in this instance we'll call it mymodule.

Create a /js directory below within that module. So I know have /sites/all/modules/custom/mymodule/js

Create a mymodule.js file in that directory with the following content:

Drupal.behaviors.password.attach = function (context, settings) {};

Then in your mymodule.module file add the following:

/**
* Implements hook_form_FORM_ID_alter
*/
function mymodule_form_user_register_form_alter(&$form, &$form_state, $form_id){
  $form['#attached']['js'][] = drupal_get_path('module', 'mymodule') . '/js/mymodule.js';
}

This will then stop the password strength indicator from displaying on the register form.

No hacking of core, using the Drupal JS API as it was intended to be used, flexible enough for you to disable on specific forms as you wish (rather than on all forms), it will handle core upgrades and the module can be enabled and disabled as you wish without any file modifications.