Skip to:
Content

BuddyPress.org

Opened 13 years ago

Closed 13 years ago

#3311 closed defect (bug) (fixed)

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

Reported by: boonebgorges's profile boonebgorges Owned by: boonebgorges's profile 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 13 years ago.

Download all attachments as: .zip

Change History (6)

#1 @djpaul
13 years ago

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

#2 @DJPaul
13 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 13 years ago by DJPaul (previous) (diff)

#3 @boonebgorges
13 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
13 years ago

#4 @boonebgorges
13 years ago

  • Priority changed from minor to normal

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

#5 @boonebgorges
13 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.