Multiple forms when resetting password in admin theme

Couldn't reproduce the page duplication, but I think it is a bug that the "Current password" field is shown. It is not required to provide the current password when a password change has been forced, because the user will have already provided that password to log in.

I think the page duplication may be due to an interaction between Password Policy and your specific site configuration. Here are the specific steps I tried from a newly installed Drupal 7.32 site:

1. Install/enable Password Policy 7.x-1.x-dev.
2. Create policy:
   • Name: foo
   • Roles: authenticated user
   • Length: 5
3. Enable policy 'foo'.
4. Add user 'foo'.
5. As administrator, check "Force password change on next login" for user 'foo' via their user page.
6. Log in as 'foo'.
7. Press "Save" without changing password. Validation fails and the page is reloaded with password fields marked as having errors. No duplication observed.

Am I missing something? Maybe you could remove non-default configuration from your site until the problem no longer occurs, to isolate what configuration is causing the problem?

Might be worth checking whether this problem occurs if the Password Policy module is not installed and a user attempts to change their password via their user page, but they enter an incorrect current password, causing validation to fail.

Added separate issue for "Current password" field bug: #2373013: Current password field should be removed for forced password changes

I got the same problem here. When a user changes the password, if he submits the form with error, it receives multiple forms (similar to the dansanjou's screenshot).

I found the issue! Actualy @AohRveTPV found here #2192361: Page duplicated.

The villain is the module Administration Menu (and its cache). My workaround was disabling admin_menu using module_invoke('admin_menu', 'suppress'); for this page only.

Thanks for making that connection. I do not see the Administration Menu in dansanjou's screenshot but I suspect it is the same general problem: Some code is making an Ajax request and expecting certain HTML as a result, but instead it is getting the user edit page due to the Password Policy redirect. To me it seems like the fault is with the Ajax requester for not properly checking the result of the request.

A solution to the problem mentioned in the previous comment (beyond better handling failed Ajax requests) may be to add a feature to allow the administrator to configure paths that are excepted from the forced-password-change redirection. If you had a safe Ajax request to foo/bar, you would configure Password Policy to not redirect to the user edit page for requests to foo/bar. Password Policy already allows system/ajax, but Ajax requests can be for different paths.

As a hack, the problematic path could be added to $allowed_paths in _password_policy_is_path_allowed_when_password_change_forced() of password_policy.module. This is only secure if it is safe for a user to be able to access the path when their password is expired.

Actually I think that the problem is caused by the ajax request of admin_menu, which forces hook_init run twice for same page. I've a similar issue on #2390851: Strict404 are printing the key of $menu_site_status on admin pages. I solved checking if the request is from a non-ajax source.

So here is a patch with this workaround. What about that?

When a password change is forced (either by expiration or manually by an administrator), the user is disallowed from accessing normal paths until they change their password. Patch in #9 would seem to allow the user to bypass this restriction just by adding the X-Requested-With header to their requests.

Also, I think the default should be to disallow access to paths used for AJAX requests, just as access is disallowed for paths used for non-AJAX requests. An AJAX request is not special--it could return data that is as sensitive as data returned by a non-AJAX request. So a site administrator may not want a user to be able to fulfill certain AJAX requests until they change their password.

Currently the module allows access to system/ajax by default, but I think this allowance should be removed.

Another possible solution would be a whitelisting approach where the administrator can specify a list of paths they wish to allow access to (e.g., for AJAX requests) even when the user is being forced to change their password.

This patch lets the administrator configure extra paths to which access will be allowed when a password change is forced. For instance, js/admin_menu/cache/* can be added to fix the page duplication caused by the Administration Menu module. Please review/test.

I am not sure whether it provides a solution to dansanjou's problem because we never determined what specifically was causing it--but it may.

Hi @AohRveTPV,

I can't apply this patch in version 1.10. I've got this messages:

File to patch: ../../../modules/contrib/password_policy/password_policy.admin.inc
patching file ../../../modules/contrib/password_policy/password_policy.admin.inc
can't find file to patch at input line 46

File to patch: ../../../modules/contrib/password_policy/password_policy.install
patching file ../../../modules/contrib/password_policy/password_policy.install
can't find file to patch at input line 58

So I applied manually (line-by-line) and its works! This patch is great, thanks!

It applies fine for me:

$ drush dl password_policy
Project password_policy (7.x-1.10) downloaded to /var/www/drupal7/sites/all/modules/password_policy.               [success]
Project password_policy contains 2 modules: password_policy_password_tab, password_policy.
$ wget -q password_policy-force_change_extra_allowed_paths-2372935-12.patch
$ patch < password_policy-force_change_extra_allowed_paths-2372935-12.patch 
patching file password_policy.admin.inc
patching file password_policy.install
patching file password_policy.module

Glad you got it to work.

Applied the patch and it does it's job to fix admin_menu problem.

I think this is only when "Password change tab" module is active. I experienced the multiple forms. Disabling it resolves the issue. Admin menu is installed.

Turns out there was already a feature request for the change that would resolve this issue: #1332000: Feature to exclude pages from force password change. Posted the patch in #12 there.

ucaka, thanks for reporting back that the patch worked.

crutch, I'm pretty sure I was able to reproduce this with Administration Menu and without Password Change Tab. It seems to be due to the cache URL used by Administration Menu (see #2192361-10: Page duplicated). It is possible when you disabled Password Change Tab it incidentally caused Administration Menu to not request the cache URL.

it's odd because it seems to be working fine without password change tab. Been testing for a few days but will keep looking to see if the issue shows itself again. Using Adaptive Theme with administrative overlay for all users. Have all caches turned on. This is all in dev but have to move to live sites this week because of gov mandate. In either case I will apply and test patch at some point today.

Maybe this is theme specific. After patch #12 I'm still getting multiple forms with Adaptive Theme Admin Theme Overlay.

This may be because the theme uses regions and the main content block is in the main content region? Not sure

When first testing after patch, it appears that there is only 1 form. Once entering the new password, then get notice "Your password has expired. You must change your password to proceed on the site." Then the second form appears below it after clicking save.

Then turn off Password change tab module and it operates normally, user can change pass.

crutch, is Administration Menu being used on the pages where the duplication occurs? If so, does the duplication still occur if Administration Menu is disabled?

Note that just applying the patch does not fix anything. It provides a new setting "Extra allowed paths" that must be configured to allow paths that are problematic. For Administration Menu, the setting needed is js/admin_menu/cache/*.

Thanks AohRveTPV In development with the patach, multiple forms are now not showing and have the settings in the new field

system/ajax
js/admin_menu/cache/*

However, when testing the process I'm now getting a warning when changing the password.

"Your current password is missing or incorrect; it's required to change the Password."

Admin menu is still disabled.

In both of these cases, I couldn't yet apply the patch on live site but needed to make live. The password change screen is the normal user edit screen, but all works well with the js criteria requirements and the strong weak scale. Experience was

Site 1
- Activate only Password Policy and not Password Change Tab
- Add Policy
- Force a password change
-- Test: It operates normally except for the js requirements and strong weak scale are not showing
- Activated Password Change Tab
- Then Deactivated Password Change Tab
- Flush all caches
- Save theme
-- Test: It operates normally with the js requirements and strong weak scale showing

Site 2
- Activate both Password Policy and Password Change Tab
- Add Policy
- Deactivate Password Change Tab
- Flush all caches
- Save theme
- Force a password change
-- Test: It operates normally with the js requirements and strong weak scale showing

However, when testing the process I'm now getting a warning when changing the password.

"Your current password is missing or incorrect; it's required to change the Password."

This is a bug in 7.x-1.10: #2426317: Missing current password with Password Change Tab. To fix you can either apply the patch from that issue or update to 7.x-1.x-dev.

Site 1
- Activate only Password Policy and not Password Change Tab
- Add Policy
- Force a password change
-- Test: It operates normally except for the js requirements and strong weak scale are not showing

This seems like it may be a different bug. Will try to reproduce it.

All okay w version 1.10 and patches from #24 and #12

- Admin menu is on
- Password change tab is on
- These settings are in the new field (Extra allowed paths) from patch #12 @url admin/config/people/password_policy
- - system/ajax
- - js/admin_menu/cache/*
- Test user can change password successfully on the password change tab

Hi AohRveTPV. Not sure if this is a symptom of this issue, which is fixed with the patches, or a separate issue that needs attention. Experience with 1.10 and not using password change tab. I will be applying #27 to live site tomorrow so we can then use password change tab.

On one of our sites there is an extra field we added to user profile "Contact Information" which is a Basic HTML Text Area.

When using 1.10 with password change tab submodule inactive, then all admin menu links are automatically inserted into the field during the password change process.

In other words, when only the Password Policy module is active and Password change tab is not active, and the user is directed to change their password on the user edit page, then admin menu links are automatically entered into the additional user profile field (textarea-basic html).

It looks like the patch from #12 was committed at some point, i see variables for password_policy_force_change_extra_allowed_paths in version 1.12.
I'm going to change the status here to fixed, but please correct me if this is not the case.

I'm still seeing this issue on v1.12, Drupal 7.50. I've not begun any investigation yet though. Has anyone else run into this?

If you're using admin_menu module along with this and have admin_menu cache setting checked, it might cause it. Take a look at https://www.drupal.org/node/1897362#comment-11627731 .

Re #32: Are you using the Administration Menu module?

If you are using Administration Menu, add js/admin_menu/cache/* to the "Extra allowed paths" field at admin/config/people/password_policy. That should fix the problem, but I haven't tested it lately. If it doesn't, please report back.

Inadvertently changed the issue version. Note that 7.x-1.12 adds the feature (#1332000: Feature to exclude pages from force password change) that should solve this problem.

Believe this is fixed per #36. Re-open if you think it may not be fixed.