Undefined index: password in password_policy_ajax_check [#2503221]

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.

Comment	File	Size	Author
#5	password_policy-7.x-2.x-undefined_index_password-2503221-5.patch	793 bytes	AohRveTPV
#5
#1	password_policy-7.x-2.x-undefined_index_password-2503221-1.patch	3.76 KB	ron_s
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

ron_s CreditAttribution: ron_s commented 9 June 2015 at 16:51

Status:

Active

» Needs review

File	Size
password_policy-7.x-2.x-undefined_index_password-2503221-1.patch	3.76 KB

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

Comment #2

AohRveTPV CreditAttribution: AohRveTPV commented 10 June 2015 at 18:23

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.

Comment #3

ron_s CreditAttribution: ron_s commented 10 June 2015 at 20:39

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.

Comment #4

AohRveTPV CreditAttribution: AohRveTPV commented 10 June 2015 at 22:20

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.

Comment #5

AohRveTPV CreditAttribution: AohRveTPV commented 10 June 2015 at 22:43

File	Size
password_policy-7.x-2.x-undefined_index_password-2503221-5.patch	793 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.

Comment #6

14 June 2015 at 01:32

AohRveTPV committed 5d7c5f7 on 7.x-2.x authored by ron_s

Issue #2503221 by ron_s: Undefined index: password in...

Comment #7

AohRveTPV CreditAttribution: AohRveTPV commented 14 June 2015 at 01:41

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.