I discovered this issue when using the Webprofiler module, a submodule of Devel. When it is enabled and a user is required to reset their password, the user's account edit page is duplicated and broken.

This is because the webprofiler module makes its own ajax request per page to a route that is not currently ignored within the password_policy event that handles redirection.

To duplicate this issue with Webprofiler:

  1. Install this module and Devel WebProfiler
  2. Create a password policy with expiration for a role your user is a member of (authenticated).
  3. Edit your account and set your password as having expired already.
  4. Visit some other page. You'll be redirected back to your account edit page, and a few seconds later another copy of the page will load at the bottom.

Update: There are a few more edge cases within Drupal core that could cause similar issues.

  • User has a ckeditor field on their profile.
  • User has a machine_name field on their profile.
  • User has an entity autocomplete field on their profile.
  • There is something on the account page that equests timezone information.

These extra cases are less straight forward to duplicate on your own, as they require the user to be attempting to edit fields at the same time that their password has expired. I figured why not go ahead and fix them while we're on the topic.

CommentFileSizeAuthor
#6 interdiff.txt1.76 KBdaggerhart
#6 2988711-6-password-expired-ajax-routes.patch1.55 KBdaggerhart
#3 2988711-3-password-expired-ajax-routes.patch732 bytesdaggerhart
#2 2988711-2-webprofiler-ajax-route.patch521 bytesdaggerhart

Comments

daggerhart created an issue. See original summary.

daggerhart’s picture

daggerhart commented
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new 2988711-2-webprofiler-ajax-route.patch521 bytes

Patch adds the webprofiler's ajax request route name to the array of route names to ignore.

daggerhart’s picture

daggerhart commented
Title: Account edit page broken when webprofiler module is enabled. » Account edit page broken when various ajax routes are executed
Issue summary: View changes
StatusFileSize
new 2988711-3-password-expired-ajax-routes.patch732 bytes

I've dug a bit deeper and found some more edge cases where this duplicate-page issue could occur. I've updated the issue title and description with more information about these additional cases.

Attached is a patch that adds each of these potentially problematic route names to the ignore list.

If applying the patch doesn't resolve the issue, refresh the browser by ignoring the browser's cache (CTRL/CMD + Shift + R)

nerdstein’s picture

nerdstein
he/him
Primary language English
Location United States
commented

I've done a code review and, yes, this looks to be totally needed. I can see how this would do a double-load of the page based on how we intercept all requests.

I am curious how this might affect some of the newer features, like system tray (off canvas stuff) since the behavior was altered for the image dialog and entity reference, which have some "similar" experiences.

@daggerhart walked me through the testing of the patch and it seems to work with some browser-caching issues outstanding. It would be great to get another set of eyes on it too before marking as RTBC.

nerdstein’s picture

nerdstein
he/him
Primary language English
Location United States
commented

Currently, there is a route-based check, which makes sense for things like the user-edit form (so it doesn't get into a redirection loop).

However, I sense the behavior we're trying to capture here is around the type of request, e.g. AJAX requests or JSON requests. The paths may routinely change, especially as changes are made in both core and contrib. A better way may be to explore if we can associate a request back to the type of request it is trying to make and mediate/restrict by type.

daggerhart’s picture

daggerhart commented
StatusFileSize
new 2988711-6-password-expired-ajax-routes.patch1.55 KB
new interdiff.txt1.76 KB

New approach. Instead of looking at every possible route, let's ignore all ajax requests. I attempted using the CONTENT_TYPE header, but it was unreliable. This patch checks the X_REQUESTED_WITH header.

dani3lr0se’s picture

dani3lr0se commented
Status: Needs review » Reviewed & tested by the community

Thanks for your work on this @daggerhart. The patch applies successfully and works well. After applying the patch I no longer see the page load twice. Huzzah!

nerdstein’s picture

nerdstein
he/him
Primary language English
Location United States
commented
Status: Reviewed & tested by the community » Patch (to be ported)

Thanks @daggerhart and for the test/review @daniel_rose. I have taken one last look and think this is great.

Merging this in.

  • nerdstein committed 52df0a8 on 8.x-3.x authored by daggerhart 
    Issue #2988711 by daggerhart, nerdstein, daniel_rose: Account edit page...
nerdstein’s picture

nerdstein
he/him
Primary language English
Location United States
commented
Status: Patch (to be ported) » Fixed

Marking as fixed, thanks everyone

Status: Fixed » Closed (fixed)

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