Skip to:
Content

BuddyPress.org

Opened 11 years ago

Closed 11 years ago

#3311 closed defect (bug) (fixed)

Inner Messages links do 404 instead of _no_access() when not logged in

Reported by: boonebgorges Owned by: boonebgorges
Milestone: 1.5 Priority: normal
Severity: Version: 1.5
Component: Messages Keywords: has-patch needs-testing
Cc:

Description

Tested on testbp.org: http://testbp.org/members/boonebgorges/messages/, when not logged in, 404s. Should use bp_core_no_access() instead. I can take a look at this sometime this week; definitely puntable if I can't get to it, as it's not a regression.

Attachments (1)

3311.1.diff (3.1 KB) - added by boonebgorges 11 years ago.

Download all attachments as: .zip

Change History (6)

#1 @djpaul
11 years ago

(In [4584]) Add missing global. See #3311

#2 @DJPaul
11 years ago

It is triggering the 404 at the bottom of bp_core_catch_no_access(); I don't know why. I noticed a global missing, so I've committed that (no change).

Last edited 11 years ago by DJPaul (previous) (diff)

#3 @boonebgorges
11 years ago

  • Keywords has-patch needs-testing added

This is actually a broader problem, which applies anytime a subnav item is added with 'user_has_access' set to false for the logged in user (which happens in BP core with Settings and Messages, but can also happen in plugins). So I went for a general fix, which adds some new logic to bp_core_new_subnav_item(), checking to see whether the user has access before hooking the screen function for the subnav (and redirecting the user appropriately if not).

Please see 3311.1.diff. I have tested the change fairly thoroughly, and am confident that it works as advertised (and with much greater clarity than before), but I would like someone else to check. Apply the patch and attempt a couple of things:
AS A LOGGED IN USER 'MEMBERNAME':

  • visit example.com/members/membername/settings (your own settings page). The page should load fine.
  • visit example.com/members/membername2/settings, where membername2 is the name of a user OTHER THAN membername. You should be redirected back to membername2's domain.
  • visit example.com/members/membername2/groups. Because this subnav is viewable by anyone, this should load fine.
  • visit example.com/members/membername3/settings, where membername3 is a NON-EXISTENT member. You should get a 404.

AS A NON-LOGGED-IN USER:

  • visit example.com/members/membername/settings. You'll be redirected back to the root domain, with a message asking you to log in. If you log in as membername, you'll be redirected to the settings page. If you log in as someone else, you'll get the "no access" message from above, and be redirected to membername's domain
  • visit example.com/members/membername/groups. Because this subnav is viewable by anyone, this should load fine.

@boonebgorges
11 years ago

#4 @boonebgorges
11 years ago

  • Priority changed from minor to normal

Also, bumping priority because it affects more than just messaging.

#5 @boonebgorges
11 years ago

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

(In [4599]) Fixes 404 and user_has_access rerouting for profile subtabs. Fixes #3311

Note: See TracTickets for help on using tickets.