WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#24771 closed defect (bug) (fixed)

Login can be blocked if primary_blog is set to a blog the user no longer belongs to that is marked as spam

Reported by: westi Owned by: nacin
Milestone: 3.7 Priority: normal
Severity: normal Version: 3.5.2
Component: Multisite Keywords: has-patch needs-codex
Focuses: Cc:

Description

We block logins for user who's primary blog is marked as spam (for historical reasons).

We don't actually check that the user is still a member of the spam blog before blocking the log in.

Which is confusing when you try and work out why they are unable to log in.

Attachments (3)

24771.diff (712 bytes) - added by westi 7 years ago.
Fix
24771.2.diff (1.0 KB) - added by martythornley 7 years ago.
Adds filter 'wp_authenticate_user_for_blog'
24771.3.diff (1.8 KB) - added by brianhogg 7 years ago.
Removes check for user blog as spam when logging in, adds replacement filter

Download all attachments as: .zip

Change History (11)

@westi
7 years ago

Fix

#1 @nacin
7 years ago

I thought we had mostly eliminated primary_blog along with the user dashboard. I guess not — but it feels like that should go into the trash too.

Patch looks good.

@martythornley
7 years ago

Adds filter 'wp_authenticate_user_for_blog'

#2 @martythornley
7 years ago

Added a new filter 'wp_authenticate_user_for_blog' to check or not check against user's primary blog.

@brianhogg
7 years ago

Removes check for user blog as spam when logging in, adds replacement filter

#3 @brianhogg
7 years ago

The patch also updates the is_user_spammy() function to take a user object, to avoid having a hard-coded 1 == $user->spam check, if that should be in a separate patch let me know.

#4 @nacin
7 years ago

  • Milestone changed from Future Release to 3.7

Related: #19714 and #20774.

#5 @nacin
7 years ago

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

In 24848:

Remove "special" multisite spam check in the authentication API.

The spamming of a site no longer directly affects a user of said site.

Moves the spam check to the wp_authenticate filter. Networks in need
of enhanced spam-fighting should leverage this same technique.

Allow is_user_spammy() to accept a WP_User object.

props willnorris, brianhogg.
fixes #24771. see #19714.

#6 @DrewAPicture
7 years ago

  • Keywords needs-codex added

#7 follow-up: @brianhogg
7 years ago

How does updating the codex for a future feature/change work - do we add an update before it's released or queue it somehow for after?

#8 in reply to: ↑ 7 @DrewAPicture
7 years ago

Replying to brianhogg:

How does updating the codex for a future feature/change work - do we add an update before it's released or queue it somehow for after?

Sometimes we edit it whenever the change is made, and sometimes we just mark needs-codex for future reference when we do the codex sprint for a new release.

When the new Code Reference is in place and auto-parsing docblocks in the source, there will be less/no need for adding the needs-codex keyword and more emphasis on providing complete inline documentation.

So in the case of this ticket, we would wait, though I anticipate the Code Reference will be in place (hopefully) before we do the 3.7 codex sprint.

Note: See TracTickets for help on using tickets.