WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#34925 closed defect (bug) (fixed)

4.4 wp-login.php: no longer possible to use the login_post scheme

Reported by: jamescollins Owned by: johnbillion
Milestone: 4.4.1 Priority: normal
Severity: normal Version: 4.4
Component: Login and Registration Keywords: fixed-major
Focuses: Cc:
PR Number:

Description

As of WordPress 4.4, the WordPress login screen uses wp_login_url() as the form action when logging in.

In WordPress 4.3.1 and older, this was using site_url( 'wp-login.php', 'login_post' ).

wp_login_url() assumes the scheme is login, which means it is no longer possible to filter for the login_post scheme and override where WordPress's login form submits to.

This change was introduced in [34213] as part of #31495.

I understand the logic behind the above change, but it does seem to be a regression because it means that the login_post scheme can't be used.

This issue affects WP Engine in particular, as they filter the login_post URL as part of their brute force login protection.

Attachments (2)

34925.patch (2.1 KB) - added by JPry 4 years ago.
Partial revert of [34213]
34925.2.patch (2.2 KB) - added by swissspidy 4 years ago.

Download all attachments as: .zip

Change History (15)

#1 @SergeyBiryukov
4 years ago

  • Milestone changed from Awaiting Review to 4.4.1

#2 @swissspidy
4 years ago

  • Keywords needs-patch added

Note that set_url_scheme still checks for login_post and site_url() / network_site_url() are still used a couple of times using login_post scheme. get_the_password_form() does so as well.

So either we partially revert [34213] or add a scheme parameter to wp_login_url(). I prefer the former.

@JPry
4 years ago

Partial revert of [34213]

#3 @JPry
4 years ago

  • Keywords has-patch added; needs-patch removed

I added a patch with the partial revert of [34213]. The revert includes any place using the login_post scheme.

#4 @DrewAPicture
4 years ago

I'd like to see @johnbillion's take on the best way to provide back-compat here. I don't think a partial revert is a particularly great solution, especially we're attempting to mildly standardize how login/registration URLs are used in core.

#5 @johnbillion
4 years ago

  • Keywords needs-patch added; has-patch removed

Setting a different target for the login form, while unusual, is certainly something we shouldn't try to prevent.

I think we can probably do something like set_url_scheme( wp_login_url(), 'login_post' ).

@swissspidy
4 years ago

#6 @swissspidy
4 years ago

  • Keywords has-patch added; needs-patch removed

As suggested, 34925.2.patch wraps wp_login_url() and wp_registration_url() with set_url_scheme() where needed.

#7 @swissspidy
4 years ago

In 35897:

Login: After [34213], use the login_post scheme again for login forms.

See #34925.

#8 @swissspidy
4 years ago

  • Keywords fixed-major added

#9 @johnbillion
4 years ago

  • Owner set to johnbillion
  • Status changed from new to accepted

#10 @johnbillion
4 years ago

  • Keywords has-patch fixed-major removed

#11 @johnbillion
4 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 36042:

Login: Revert [34213] and [35897]. It has become apparent that there is a need for a separate function (and corresponding filter) which allows for the login form action URL to differ from the URL used to access the login form, so that plugins or implementations which change the login URL do not need to worry about handling the form submission at the same URL.

For now, we'll revert to the pre-4.4 behaviour of hard-coding the login form action URL as wp-login.php and look at implementing a separate function and corresponding filter in 4.5.

Props KrissieV, salcode, JPry
Fixes #34925
See #35103

#12 @johnbillion
4 years ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

#13 @johnbillion
4 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 36043:

Login: Revert [34213] and [35897]. It has become apparent that there is a need for a separate function (and corresponding filter) which allows for the login form action URL to differ from the URL used to access the login form, so that plugins or implementations which change the login URL do not need to worry about handling the form submission at the same URL.

For now, we'll revert to the pre-4.4 behaviour of hard-coding the login form action URL as wp-login.php and look at implementing a separate function and corresponding filter in 4.5.

Merges [36042] to the 4.4 branch.

Props KrissieV, salcode, JPry
Fixes #34925
Fixes #35103

Note: See TracTickets for help on using tickets.