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

[dsixinetu]

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.

<!--
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:

• FAQs for New Contributors: ​https://make.wordpress.org/core/handbook/tutorials/faq-for-new-contributors/
• Contributing with Code Guide: ​https://make.wordpress.org/core/handbook/contribute/
• WordPress Coding Standards: ​https://make.wordpress.org/core/handbook/best-practices/coding-standards/
• Inline Documentation Standards: ​https://make.wordpress.org/core/handbook/best-practices/inline-documentation-standards/
• Browser Support Policies: ​https://make.wordpress.org/core/handbook/best-practices/browser-support/
• Proper spelling and grammar related best practices: ​https://make.wordpress.org/core/handbook/best-practices/spelling/

-->

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

[adamsilverstein]

Thanks for the ticket @dsixinetu and the steps to reproduce. We will take a look!

[adamsilverstein]

@dsixinetu - Thanks for the bug report! I was able to reproduce the issue as you described.

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

Probably best to keep those changes in a separate ticket. Do you think you can work on an updated patch that only includes the "proposed fix" part?

[dsixinetu]

@adamsilverstein I've updated the pull request to only include the changes mentioned in "proposed fix", thanks for taking the time to look at this.

[dsixinetu]

I've created #50305 for the broader question of cleaning up the interval

[azaozz]

Confirmed. Happens only on the (old) Edit Post screen.

The change in #28962 was designed to...

Yeah, [35568] completely disables this which doesn't seem a good solution.

Looking at ​https://github.com/WordPress/wordpress-develop/pull/176, don't think the changes there address this bug very well. Seems a better/simpler solution is to just add a timeout when the user closes the modal. Patch coming up.

[azaozz]

In 49573.diff: When a user dismisses the "Please log in again" modal without logging in, add a 5 min. timeout before showing the modal again.

[azaozz]

In 49573.1.diff:

• Refresh after [48056].
• Some cleanup and coding standards fixes.

[azaozz]

In 48337:

Heartbeat: Do not disable the login prompts when the user needs to log in again but has closed the log in modal. Add a 5 minutes timeout before asking them to log in again.

Props dsixinetu, adamsilverstein, azaozz.
Fixes #49573.

[SergeyBiryukov]

In 48339:

Coding Standards: Fix JSHint issue in js/_enqueues/lib/auth-check.js

See #49573.