Spammed users should not be able to reset their password

[r-a-y]

In multisite, if an admin has marked a user as spam, the spammed user can still attempt to reset their password.

Even though spammed users cannot login, we shouldn't be able to let spammers to reset their password.

Attached patch addresses this.

[r-a-y]

Disregard the wrong ticket number for the patch!

Forgot to write that the patch also passes the $user_data object to the 'allow_password_reset' filter so plugin devs can use the already-queried $user_data object to do their checks in order to disable password resetting.

[SergeyBiryukov]

This should be a distinct spammer_account error code, rather than invalid_username (see #19445).

[r-a-y]

Right, nice catch, SergeyBiryukov.

I was working off the 3.5-branch instead of trunk.

[johnbillion]

A generic error message might be more desirable here. Eg. "Your account has been disabled".

[chriscct7]

Needs implementation of comment:4 and a refresh

[jeremyfelt]

24617.01.patch​ is a good starting patch, agreed on the change in error messaging. Also, I'd go with spam account and marked as spam vs spammer in the docs.

[websupporter]

Updates the patch and utilizes is_user_spammy()

[websupporter]

Sorry for spamming myself :D, just wanted to add the spaces between if(){ correctly.

[jeremyfelt]

Thanks @websupporter, 24617.03.patch​ is looking good. Let's change the error text to something more generic so that we're not necessarily passing that info on to the user. The suggested "Your account has been disabled" from above seems right. Thoughts?

[websupporter]

Hi @jeremyfelt, if we just put $allow to false, we retun Password reset is not allowed for this user as the standard not allowed. Or we go with an extra message disabled where we might be able to keep the error code for some purposes specific.

I would opt for $allow false since its the most generic we have.

[jeremyfelt]

Replying to websupporter:

if we just put $allow to false, we retun Password reset is not allowed for this user as the standard not allowed.

Ahh, +1 for this then. I think keeping it generic and using the same messaging as other possible reasons makes sense.

[websupporter]

set $allow to false instead of a new WP_Error

[jeremyfelt]

This is looking good. I'm going to go with the multisite/spammy check here and leave the changes to the allow_password_reset filter for another ticket/discussion. We haven't needed to pass the full user object before. If anyone would like to extend that filter, please open another ticket.

[jeremyfelt]

In 37317:

Users: Prevent spammy users from resetting their passwords in multisite

Props r-a-y, websupporter.
Fixes #24617.