Hi DrupalGap developers,

I'm new to submitting bug reports, so please don't be too upset if this was submitted incorrectly.

As it stands right now, the DrupalGap 7 module doesn't seem to do any real form validation on the Current Password field of the User Profile Edit form. I don't know whether DrupalGap works that way by design, or if this was an unintentional omission, but it is a pretty glaring omission.

Right now this is what the validation function looks like:

/**
 * The user profile form validate handler.
 * @param {Object} form
 * @param {Object} form_state
 */
function user_profile_form_validate(form, form_state) {
  try {
    // If they entered their current password, and entered new passwords, make
    // sure the new passwords match.
    if (!empty(form_state.values['current_pass'])) {
      if (
        !empty(form_state.values['pass_pass1']) &&
        !empty(form_state.values['pass_pass2']) &&
        form_state.values['pass_pass1'] != form_state.values['pass_pass2']
      ) {
        drupalgap_form_set_error('pass_pass1', t('Passwords do not match.'));
      }
    }
    // If they didn't enter their current password and entered new passwords,
    // tell them they need to enter their current password.
    else if (
      empty(form_state.values['current_pass']) &&
      !empty(form_state.values['pass_pass1']) &&
      !empty(form_state.values['pass_pass2'])
    ) {
      drupalgap_form_set_error(
        'current_pass',
        t('You must enter your current password to change your password.')
      );
    }
  }
  catch (error) { console.log('user_profile_form_validate - ' + error); }
}

As you can see, the validator function never checks whether the Current Password the user enters is actually correct.

If this should be a feature request instead of a bug, that's fine. Just let me know. Thanks!

Comments

J2 created an issue. See original summary.

tyler.frankenstein’s picture

Status: Active » Postponed (maintainer needs more info)

Welcome to the Drupal issue queues! During the form submission in DrupalGap, the user account object is passed to jDrupal's user_save(), which in turn passes it to the Services module's User Update resource. This resource takes care of the validation server side.

See here: http://cgit.drupalcode.org/services/tree/resources/user_resource.inc?h=7...

The incoming data is spoofed into a user profile form submission, so normal Drupal core form validation will take place, thus protecting a password change without the current password.

If this is not true, and you're able to change a user account's password, without entering the current password, let me know, then I think we'll need to migrate this issue to the Services module.

J2’s picture

Hi Tyler,

Thanks for replying so quickly! Interesting to find out that the validation is done server-side - that certainly makes a lot more sense from a security standpoint.

I'm confused about what you mean by the data being "spoofed into a user profile." Are you saying that the User Update Resource (in the Services Module) doesn't actually check the Current Password field value, or are you saying that it does?

Right now the behavior I am observing is that the form does require me to enter some value for the Current Password, but it doesn't require that value to match the user's actual current password. I am able to enter any value, so long as it is not null or '', and the form validates just fine.

tyler.frankenstein’s picture

When I say "spoof a user profile form submission", the service on the server side, programmatically loads up a Drupal form, fills in the data of that form with the JSON data that was passed to it from the external app (in this case DrupalGap), then tells Drupal to submit the form (just like if someone were visiting your Drupal website). This then runs the submitted data through all the normal validation procedures. This design has pros/cons, and is how most Service Resources work.

To change an account password, the user must enter their current password, and 2 copies of the new password, then submit it to Drupal. User #1 can probably get around this validation, but every other user must do this. If that isn't happening, then this will need attention in the Service module. Please advise.

tyler.frankenstein’s picture

Category: Bug report » Support request
Priority: Major » Normal
J2’s picture

Aha! So sorry for the long wait for a reply, but it turns out that this was in fact working as designed.

The Current Password field only validates the input value if the user is changing his/her password. Any other user account changes don't require that field to validate. I understand how it works now.

Thanks for your help!

J2’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)