Persist third-party plugin $_POST fields across the 2FA login screen (Fixes #705)

[chetanupare]

What?

This PR ensures that custom $_POST fields injected by third-party plugins (e.g., JavaScript detection flags, custom checkboxes) into the WordPress login form are preserved when the Two-Factor plugin interrupts the login flow to display its 2FA challenge.

Fixes #705

Why?

Currently, when a user successfully passes the initial username/password check, Two-Factor renders the login_html() interstitial form. In doing so, it drops any non-standard $_POST variables submitted from the original wp-login.php form. When the user eventually submits their 2FA code, plugins that rely on $_POST (for instance, during the attach_session_information hook) fail to find their data.

How?

A new recursive method Two_Factor_Core::print_custom_post_fields() has been added.

1. It iterates over $_POST and outputs hidden elements for each field.
2. It uses a rigorous blocklist to prevent echoing standard WordPress core fields (like log, wp-submit, _wpnonce, etc.), Two-Factor specific fields, and most importantly, passwords (pwd, password, user_pass). This ensures absolute security so that plaintext passwords are never inadvertently written to the HTML source code.
3. Unit tests have been added to verify that custom fields (including nested arrays) are properly passed through, and that sensitive fields are rigorously blocked.

Use of AI Tools

AI assistance: No

Testing Instructions

1. Install and activate a plugin that adds a custom field to the WP login form (e.g., nocache-bfcache from the issue, or write a simple mu-plugin that adds an using the login_form hook).
2. Attempt to log in with an account that has Two-Factor enabled.
3. On the 2FA interstitial screen, inspect the HTML source code.
4. Verify that the custom field (my_custom_field) is present as a hidden input.
5. Verify that sensitive fields (like pwd, password, user_pass, log, etc.) are absolutely not present in the hidden inputs.
6. Verify that standard authentication still works normally.

Changelog Entry

Fixed - Preserve custom third-party $_POST variables during the 2FA login challenge.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: chetanupare <chetanupare@git.wordpress.org>
Co-authored-by: dd32 <dd32@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Copilot]

Pull request overview

This PR improves Two-Factor’s interrupted-login flow by preserving third-party $_POST fields across the 2FA interstitial form so downstream hooks (e.g., attach_session_information) can still read plugin-injected login inputs after 2FA completes.

Changes:

• Adds a core helper to render non-blocklisted $_POST fields as hidden inputs on the 2FA interstitial form (including nested arrays).
• Adds unit tests for the new $_POST passthrough behavior.
• Introduces a new session-revalidation action/API (two_factor_revalidate_session / action_revalidate_session()), which is not described in the PR’s stated scope.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
class-two-factor-core.php	Prints custom $_POST fields into the 2FA interstitial form; adds a new session revalidation action/API.
tests/class-two-factor-core.php	Adds unit tests covering custom $_POST passthrough and the new revalidation redirect behavior.

Comments suppressed due to low confidence (1)

tests/class-two-factor-core.php:2767

• This test also needs to avoid exit; if a redirect happens unexpectedly. Using do_redirect_callable() lets the test assert that no redirect occurred without risking the process terminating.

		// Should not throw an exception (no redirect)
		$exception = false;
		try {
			Two_Factor_Core::action_revalidate_session( 300 );
		} catch ( Two_Factor_Redirect_Exception $e ) {
			$exception = true;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chetanupare]

Hi @masteradhoc , I've cleaned up this PR branch ! The unrelated hook commit is gone, the $_POST fields are now properly unslashed, and the blocklist correctly handles nested arrays now.
Let me know if it looks good !