Hi,

I have a user_profile_form with custom #ajax fields. When the password_policy module sets the password expired for a user, the #ajax fields callback return an error.

Looking in password_policy module I found the function password_policy_init():

/**
 * Implements hook_init().
 */
function password_policy_init() {
  global $user;

  // Timing issues require reloading the user object
  // to get the password_change property set.
  $account = user_load($user->uid);

  // Check password reset status and force a reset if needed.
  $change_password_url = 'user/' . $account->uid . '/' . (module_exists('password_policy_password_tab') ? 'password' : 'edit/account');
  if ($account->force_password_change && $_GET['q'] != $change_password_url) {
    // let users log out
    // Marco FIX
    if (current_path() != 'user/logout') {
      drupal_set_message(t('Your password has expired. You must change your password to proceed on the site.'), 'error', FALSE);
      drupal_goto($change_password_url, array('query' => drupal_get_destination()));
    }
  }
}

As you can see, when the password is expired, the init() function redirect the user to $change_password_url if the current path is not equal to user/logout, in order to force the password change.

So what happens is that when the form ajax callback is executed on standard path system/ajax, this callback is intercepted by the init() function and not completed because of the redirect.

Fix that problem was easy for me, just replacing the 40 line with:

if (current_path() != 'user/logout' && current_path() != 'system/ajax') {

I think that this is an important issue to fix, would you like to insert the fix in the module?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

erikwebb’s picture

I agree we should whitelist AJAX URLs. Can you provide a patch?

mecmartini’s picture

Status: Active » Needs review
FileSize
790 bytes

Here the patch :)

erikwebb’s picture

Status: Needs review » Patch (to be ported)

Thanks!

http://drupalcode.org/project/password_policy.git/commit/a5538b2

I assume this is a problem for D6 as well.

erikwebb’s picture

Version: 7.x-1.5 » 6.x-1.x-dev
AohRveTPV’s picture

Status: Patch (to be ported) » Fixed

D6 does not have built-in Ajax support, so this does not seem to be a problem for 6.x. There is no #ajax in the D6 FAPI:
https://api.drupal.org/api/drupal/developer!topics!forms_api_reference.h...

D6 does have AHAH, which I don't know much about, but it looks like that uses a user-specified callback path instead of a single default one like system/ajax. Password Policy 6.x allows administrator-specified "exclude" paths, so administrators could exclude their AHAH callback paths.

7.x-2.x already allows system/ajax, so I believe this issue is fixed.

Status: Fixed » Closed (fixed)

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