Skip to:

Opened 5 years ago

Last modified 5 years ago

#3262 assigned enhancement

Invalidate user cookies when blocked role is applied

Reported by: pierlo's profile pierlo Owned by: johnjamesjacoby's profile johnjamesjacoby
Milestone: 2.7 Priority: high
Severity: normal Version: trunk
Component: API - Roles/Capabilities Keywords: has-patch dev-feedback


As discussed in #4691 on the WP Trac, assigning the 'blocked' role to a user should invalidate their cookies. In bbPress 1.2, this was done by appending '---' to the password hash.

Testing this method does not work in WordPress 5.3, and instead in the patch attached I've gone with prefixing an underscore to the hash. This produces an invalid hash when being compared with a plaintext password, and thus logins fail without error.

One thing to note is when default roles are being remapped, it will 'fix' the broken hashes if the user was previously blocked.

Attachments (1)

3262.patch (5.7 KB) - added by pierlo 5 years ago.

Download all attachments as: .zip

Change History (8)

5 years ago

This ticket was mentioned in Slack in #bbpress by pierlo. View the logs.

5 years ago

#2 @johnjamesjacoby
5 years ago

I think this patch is a good first effort.

Remember that the default experience in bbPress is that Forum roles are separate from Site roles, so it is expected for a user account to be Blocked from the Forums without also being Blocked from the Site.

Perhaps we consider adding a setting to allow Forum owners to set what happens when a user is blocked? For example, a multisite installation may also want to mark that account as Deleted or Spam? What do you think?

#3 @pierlo
5 years ago

That make sense. I guess that would reside in the Forums Settings with options like "Block from forums and site" and "Block from forums only". Wouldn't want too much options deviating from that.

#4 @johnjamesjacoby
5 years ago

  • Milestone changed from Awaiting Review to 2.6
  • Owner set to johnjamesjacoby
  • Status changed from new to assigned

I have some ideas for this that I won't have time to implement before 2.6 is ready, so I'm moving this to 2.6.1.

#5 @johnjamesjacoby
5 years ago

  • Milestone changed from 2.6 to 2.6.1

Whoops. Wrong milestone!

#6 @johnjamesjacoby
5 years ago

  • Milestone changed from 2.6.1 to 2.6.2

Move these to 2.6.2.

#7 @johnjamesjacoby
5 years ago

  • Milestone changed from 2.6.2 to 2.7
Note: See TracTickets for help on using tickets.