Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 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's profile westi Owned by: nacin's profile 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 12 years ago.
Fix
24771.2.diff (1.0 KB) - added by martythornley 12 years ago.
Adds filter 'wp_authenticate_user_for_blog'
24771.3.diff (1.8 KB) - added by brianhogg 12 years ago.
Removes check for user blog as spam when logging in, adds replacement filter

Download all attachments as: .zip

Change History (11)

@westi
12 years ago

Fix

#1 @nacin
12 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
12 years ago

Adds filter 'wp_authenticate_user_for_blog'

#2 @martythornley
12 years ago

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

@brianhogg
12 years ago

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

#3 @brianhogg
12 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
12 years ago

  • Milestone changed from Future Release to 3.7

Related: #19714 and #20774.

#5 @nacin
12 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
12 years ago

  • Keywords needs-codex added

#7 follow-up: @brianhogg
12 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
12 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.