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:
- Log in and edit a post
- Log out in a separate window
- When prompted to log in, do so
- 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
- Move the
wp.heartbeat.connectNow()
call to theload
handler of the login dialog frame - it will run if the user logs in, but not if the close button is used - Leave the
heartbeat-tick.wp-auth-check
in place, this will cause the login dialog to re-appear, but we can delay that with: - 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.
<!--
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
wp-auth-check
is sent on every heartbeat regardlessTrac ticket: https://core.trac.wordpress.org/ticket/49573