Minor issue, but we're occasionally seeing the following PHP error in our logs:

Notice: Undefined index: password in password_policy_ajax_check() (line 28 of /sites/all/modules/password_policy/password_policy.module).

I would assume this probably has to do with a bot moving through the fields faster than Ajax can process the results. Suggesting that the code in password_policy_ajax check be wrapped with a conditional.

Will add a patch in a minute.

CommentFileSizeAuthor
#5 password_policy-7.x-2.x-undefined_index_password-2503221-5.patch793 bytesaohrvetpv
#1 password_policy-7.x-2.x-undefined_index_password-2503221-1.patch3.76 KBsgdev

Comments

sgdev’s picture

sgdev commented
Status: Active » Needs review
StatusFileSize
new password_policy-7.x-2.x-undefined_index_password-2503221-1.patch3.76 KB

Patch is attached for review. Just a simple conditional to check if $_POST['password'] is set.

aohrvetpv’s picture

aohrvetpv commented

Unable to reproduce so far. I tried:
1. Rapidly pressing key in password field.
2. Using KeePassX to auto-type password with keystroke delay of 5ms. (I am not sure if this causes a JavaScript keyup event, though.)

Any suggestion how to reproduce? Can you reproduce this on a fresh Drupal site with only Password Policy installed? I am wondering if there is something different about your configuration.

sgdev’s picture

sgdev commented

I'm not sure I have a clear way to reproduce. My assumption is it's a combination of a bot moving through the field quickly, plus Ajax responding slowly.

There is very little performance tuning on the site where this is occurring (the client does not want to invest in tuning at this time). Therefore there are regularly situations where the Ajax can be sluggish -- might take 2-3 seconds to respond.

aohrvetpv’s picture

aohrvetpv commented

I wonder if the form is being submitted before this line in the JavaScript executes, which is executed before the POST to /password_policy/check:

var data = { password: encodeURIComponent(passwordInput.val()) };

If so, there would be no password input from which to get the value.

I can't cause this to happen in Firefox. If this is the problem, logging of the HTTP requests should show a POST request for /password_policy/check after the POST to submit the form.

aohrvetpv’s picture

aohrvetpv commented
StatusFileSize
new password_policy-7.x-2.x-undefined_index_password-2503221-5.patch793 bytes

Am wondering if this patch would also fix. The only way I can see for the password to not be a parameter in the request is if the password input has no value. This fix would be better than #1 because it would avoid a bogus request.

  • AohRveTPV committed 5d7c5f7 on 7.x-2.x authored by ron_s 
    Issue #2503221 by ron_s: Undefined index: password in...
aohrvetpv’s picture

aohrvetpv commented

Went ahead and committed #1:
- It is probably not a bad idea to check that the password parameter exists even if it is not fixing the root problem.
- I suspect the AJAX callback would be better implemented using Form API #ajax. Not sure why it was implemented the way it was, not using the Form API. I will try to write a patch to use Form API #ajax, and if it works the code in password_policy_ajax_check() would probably be replaced, which means this change may not matter so much.

aohrvetpv’s picture

aohrvetpv commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.