WordPress.org

Make WordPress Core

Opened 2 hours ago

Last modified 111 minutes ago

#49573 new enhancement

Improve wp-auth-check, allowing multiple logins on the post page

Reported by: dsixinetu Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: trunk
Component: Administration Keywords: has-patch
Focuses: javascript, administration Cc:

Description

Normally, if the auth-check determines that the user is not authenticated it will call show(), displaying a login dialog and allowing the user to log in again. When on the post page, this works the first time but fails thereafter.

Steps to reproduce:

  1. Log in and edit a post
  2. Log out in a separate window
  3. When prompted to log in, do so
  4. Log out again from a separate window

Expected result:
The login dialog should be displayed so that the user can log in again

Actual result:
The login dialog is not displayed

Explanation
The change in #28962 was designed to allow a user to close the login dialog and then interact with the content on screen without having the dialog immediately re-appear. This is done by removing the event handler that displays the login dialog when the heartbeat response indicates that the user is not authenticated. Since the event handler is removed and not re-added, the result is that after hide() is called, the login dialog will not be shown again. This affects both closing the dialog with the X and logging in (which will result in a heartbeat response with wp-auth-check set to true.

Proposed fix

  1. Move the wp.heartbeat.connectNow() call to the load handler of the login dialog frame - it will run if the user logs in, but not if the close button is used
  2. Leave the heartbeat-tick.wp-auth-check in place, this will cause the login dialog to re-appear, but we can delay that with:
  3. Set the next heartbeat to the maximum interval if the close button is clicked. This gives the user 120 seconds to interact with the page before the login dialog reappears

Other cleanup
Also in this branch is some cleanup of the auth-check system, I'm not sure if this needs to be a separate ticket/patch:
In #27081, the wp-auth-check data was inserted into every heartbeat response rather than waiting for wp-auth-check in the request. As a result, the request and the associated scheduling logic and filter have no effect. I've removed the superfluous code.

Change History (1)

This ticket was mentioned in PR #176 on WordPress/wordpress-develop by dsix-work.


111 minutes ago

<!--
Hi there! Thanks for contributing to WordPress!

Pull Requests in this GitHub repository must be linked to a ticket in the WordPress Core Trac instance (https://core.trac.wordpress.org), and are only used for code review. No pull requests will be merged on GitHub.

See the WordPress Handbook page on using PRs for Code Review more information: https://make.wordpress.org/core/handbook/contribute/git/github-pull-requests-for-code-review/

If this is your first time contributing, you may also find reviewing these guides first to be helpful:

-->

Improve auth-check

  1. Remove scheduling/request data, since wp-auth-check is sent on every heartbeat regardless
  2. Modify the mechanism for hiding the login dialog so that users can both:
    1. Close the dialog and interact with the page for some time without the dialog re-appering
    2. Log in repeatedly without navigating to a new page

Trac ticket: https://core.trac.wordpress.org/ticket/49573

Note: See TracTickets for help on using tickets.