Skip to:
Content

Opened 6 years ago

Last modified 5 years ago

#2069 reopened defect

Anonymous users can always spectate

Reported by: kevinB Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.2.2
Component: API - Roles/Capabilities Keywords: needs-patch
Cc: kevin@…

Description

The spectate capability is not useful because anonymous users have it implicitly. Blocked users lose all forum access (including viewing) but can again read public forums after logging out. In addition to this nonsensical anonymous > blocked behavior, the inconsistent handing of the spectate cap means it cannot be withheld from anonymous users nor verified via allcaps or current_user_can().

This could be remedied by including the spectate capability in the blocked role and mapping that role to anonymous users. The role map and caps could of course be filtered for sites that need to prevent both anon and blocked users from spectating (or need blocked users to have some additional access beyond anonymous).

Attachments (1)

anon-spectate-filterable.diff (2.9 KB) - added by kevinB 6 years ago.

Download all attachments as: .zip

Change History (11)

#1 @johnjamesjacoby
6 years ago

  • Milestone changed from Awaiting Review to Future Release

Maybe the problem is verbiage: blocked VS banned?

Either way, once you allow anonymous posting, the concept of blocking/banning registered user accounts is pretty pointless.

#2 follow-up: @kevinB
6 years ago

The issue is not anonymous posting, but viewing. Anonymous users can always read any public forum, while blocked users cannot (due to lack of spectate capability).

How is the spectate capability meaningful in this arrangement?

Last edited 6 years ago by kevinB (previous) (diff)

#3 in reply to: ↑ 2 @johnjamesjacoby
6 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to kevinB:

How is the spectate capability meaningful in this arrangement?

The idea is to send a message to a registered user that they are no longer welcome in your community, by blocking them from reading and writing to your forums. Sure, they can just log out, and if your forums are public (as they are by default) then that user will be able to read the forums again; if you enable anonymous posting, anyone is free to post whatever they like, registered or not.

I don't consider this a bug, I consider it a feature of the "Blocked" role. Closing as wontfix, but happy to keep discussing here. If I'm misunderstanding the issue, or there's a more logical capability arrangement worth exploring, we can figure that out here.

#4 @kevinB
6 years ago

  • Cc kevin@… added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Thanks for explaining the reasoning for spectate blocking. It still seems a little quirky to me but, like you said, it does send a message.

Aside from that functional issue, what do you think about handling the spectate cap as a normal capability by adding it to $user->allcaps for anonymous users and then making bbp_forum_enforce_blocked() call current_user_can('spectate') regardless of login? That way plugins could check for or modify the anon user's spectate access in the normal ways.

#5 @johnjamesjacoby
6 years ago

The problem with that approach is there is no user to attach capabilities to if you're anonymous. Registered users with no roles are granted the 'exist' capability, but that's it. Since anonymous users have no entry in the database, and only have comment cookies, there's no persistence we can trust.

#6 @kevinB
6 years ago

How about just appending the allcaps array dynamically in bbp_set_current_user_default_role():

if ( ! is_user_logged_in() ) {
   $bbp = bbpress();
   $bbp->current_user->allcaps['spectate'] = true;
   return;
}

I don't see that "hardcode" as being any worse than the implicit hardcode that's done in bbp_forum_enforce_blocked() now. At least then current_user_can() would be consistent and plugins could hook into bbp_setup_current_user late to remove the capability.

Mapping a role to anonymous users / non-members would be even better, but a more elaborate change.

#7 follow-up: @johnjamesjacoby
6 years ago

It seems like it could work, though it's a bit unorthodox. I'm not sure since when, but the $current_user global is set to a WP_User object, even for anonymous users. So like you say, we could safely give them a role on the site.

Worth tinkering with.

#8 in reply to: ↑ 7 @johnjamesjacoby
6 years ago

The only other issue I see with anonymous users is page caching. Since most caching happens for anonymous users, it's possible that bbPress won't even have a chance to manipulate the $current_user. Not sure what exactly a work-around would be there.

#9 @kevinB
6 years ago

It would be nice if WP had a request_cache_flush() function that fired a corresponding action. Then caching plugins (regardless of their implementation) could be formally encouraged to implement the action as a WP 3.6 (and bbPress 2.3) compat issue.

Last edited 6 years ago by kevinB (previous) (diff)

#10 @netweb
5 years ago

  • Keywords needs-patch added
  • Milestone set to Future Release

Putting a milestone back in the ticket

Note: See TracTickets for help on using tickets.