WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

#34401 closed enhancement (fixed)

Search mechanisms complaning of access denied error on wp-login.php?action=logout

Reported by: rodrigosprimo Owned by: jeremyfelt
Milestone: 4.6 Priority: normal
Severity: normal Version:
Component: Login and Registration Keywords: has-patch
Focuses: Cc:

Description

In one of my sites, Google Webmaster is complaining of access denied errors in thousands of variations of the wp-login.php?action=login URL (with different values for the _wpnonce param).

Those pages are generated by _default_wp_die_handler() and this function doesn't include a noindex robots meta tag in the header. I'm assuming adding such meta tag is the best way to fix this issue. It seems reasonable to me to have noindex on error pages but I'm not sure if this is a good idea since this is not my area of expertise.

I noticed that I'm not the only one having this issue:

https://wordpress.org/support/topic/google-showing-login-access-denied https://productforums.google.com/forum/#!topic/webmasters/XnOFn2CgGyQ https://forums.digitalpoint.com/threads/webmaster-url-crawl-error-for-wordpress-wp-login-php-action-logout-_wpnonce.2219262/

Thoughts?

Attachments (2)

34401.patch (511 bytes) - added by rodrigosprimo 3 years ago.
34401.diff (544 bytes) - added by jeremyfelt 2 years ago.

Download all attachments as: .zip

Change History (15)

@rodrigosprimo
3 years ago

#1 @SergeyBiryukov
3 years ago

  • Component changed from General to Login and Registration

#2 @swissspidy
3 years ago

  • Keywords has-patch added

#3 @johnbillion
2 years ago

  • Milestone changed from Awaiting Review to 4.6

#4 @johnbillion
2 years ago

  • Owner set to johnbillion
  • Resolution set to fixed
  • Status changed from new to closed

In 37210:

Add noindexing to the default wp_die() handler to avoid unnecessary crawl errors in web search engines.

Fixes #34401
Props rodrigosprimo

#5 @jeremyfelt
2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

wp_no_robots() isn't defined until wp-includes/general-template.php is loaded. It's possible that a rare scenario in wp_not_installed() causes wp_die() to fire before wp_no_robots() is available, causing a fatal error.

We may need to move wp_no_robots() up a bit or just insert the meta tag manually in this case.

#6 @jeremyfelt
2 years ago

It appears this can happen via dead_db() as well.

This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.


2 years ago

@jeremyfelt
2 years ago

#8 @jeremyfelt
2 years ago

34401.diff adds a function_exists check for wp_no_robots(), similar to what we do for language_attributes(). See #3231.

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


2 years ago

#10 @jeremyfelt
2 years ago

  • Owner changed from johnbillion to jeremyfelt
  • Status changed from reopened to reviewing

This ticket was mentioned in Slack in #core by voldemortensen. View the logs.


2 years ago

#12 @screamingdev
2 years ago

Please please please, no final classes. We as devs like to extend WordPress, not being blocked by it :(

#13 @jeremyfelt
2 years ago

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

In 37689:

Login: Fire wp_no_robots() in wp_die() only if function exists.

This covers cases where wp_die() is used before general-template.php is loaded.

Fixes #34401.

Note: See TracTickets for help on using tickets.