Bug #2239
closedLogin redirects when clicking on private group addresses not working
Added by Matt Gold almost 12 years ago. Updated almost 10 years ago.
0%
Description
When I clicked on a link to a private group forum post while being in a logged out state, I received an error message instead of a chance to log in and then a redirection to the page I was trying to see.
The attached screenshot shows what I saw when I clicked on the link to the private group forum post.s
Files
Screen_Shot_2012-11-09_at_4.06.05_PM.png (72.1 KB) Screen_Shot_2012-11-09_at_4.06.05_PM.png | Matt Gold, 2012-11-09 04:08 PM | ||
Screen_Shot_2012-11-09_at_9.29.19_PM.png (176 KB) Screen_Shot_2012-11-09_at_9.29.19_PM.png | Matt Gold, 2012-11-09 09:33 PM | ||
Screen_Shot_2012-11-11_at_9.46.17_PM.png (79 KB) Screen_Shot_2012-11-11_at_9.46.17_PM.png | Matt Gold, 2012-11-11 09:51 PM | ||
Screen Shot 2013-08-19 at 5.03.27 PM.png (71.9 KB) Screen Shot 2013-08-19 at 5.03.27 PM.png | Matt Gold, 2013-08-19 05:04 PM |
Updated by Matt Gold almost 12 years ago
Strange. On a different machine, this worked as expected. See second screenshot.
Updated by Dominic Giglio almost 12 years ago
Matt,
Could you tell me a little more about what computer you were on when you experienced the original error? I'm wondering if this could be related to our ongoing login issues related to cookies. #228, #2193.
If it is, we might want to start another meta ticket to consolidate login discussions the way we did with CAC Featured Content while I was rewriting it.
Updated by Boone Gorges almost 12 years ago
- Assignee changed from Boone Gorges to Dominic Giglio
- Target version changed from 1.4.10 to 1.4.11
I'm wondering if this could be related to our ongoing login issues related to cookies.
I doubt it. I'd bet that this is due to some checking that BP does to check for content access. Individual components (bp-groups, bp-members, etc) are reponsible for checking whether URL requests correspond to existing content; when content is found, but the current user does not have permission to use it, components use bp_core_no_access()
to handle the login redirect stuff. I'm guessing that the groups/forums components are not properly configured to do this, in part because the URLs have so many parts. That would suggest that this is a BP issue.
I've copied Ray, as he was the original author of the bp_core_no_access()
feature.
Updated by Raymond Hoh almost 12 years ago
I think we get the "Page Not Found" page because that group is a hidden group.
We've always thrown a "Page Not Found" for hidden groups in BP:
https://buddypress.trac.wordpress.org/browser/tags/1.6.1/bp-groups/bp-groups-loader.php#L254
This doesn't help when we're using the Group Email subscription plugin.
What's a good plan of attack, Boone? Perhaps check to see if a hidden group URL has an action, if so, use bp_core_no_access()
instead of throwing a 404?
Updated by Matt Gold almost 12 years ago
Computer #1 (Error message + redirection): Macbook Air, OS X, Chrome
Computer #2: (Expected behavior -- told to log in to that specific group): Macbook Pro (older), OS X, Chrome
So, here's some weirdness: I just tried this again on computer #1, and things worked as expected, except for the fact that the login message I saw didn't quite match the message I saw before in Screenshot #2 (Screen_Shot_2012-11-09_at_9.29.19_PM.png)
I should probably make sure that these errors are all for the same things (ie., forum posts in private groups as opposed to docs or files). I can't promise that that's the case
Updated by Boone Gorges almost 12 years ago
- Assignee changed from Dominic Giglio to Raymond Hoh
What's a good plan of attack, Boone? Perhaps check to see if a hidden group URL has an action, if so, use bp_core_no_access() instead of throwing a 404?
Hm. The reason we throw 404s for hidden groups is that we don't want to let on that these groups exist at all, much less that a specific piece of group content exists. If there's a hidden group called boone-sucks, I shouldn't be able to find out that it exists by guessing at group name. Same for forum URLs (though it's extremely unlikely that someone would be guessing hidden URLs like this).
One thought is that we might proceed is to add a hash to URLs sent through BPGES that would allow these items to go to bp_core_no_access()
rather than 404ing. That way, authorized users would have the expected redirect_to behavior when clicking from email notifications, while URL-guessers would still get 404s. Ray, do you think it's possible to do this without too much overhead from within GES? Do we have the proper hooks in place in BP?
Updated by Boone Gorges over 11 years ago
- Target version changed from 1.4.11 to 1.4.12
Updated by Raymond Hoh over 11 years ago
Boone, I was thinking about this issue yesterday when I was looking into GES.
We could probably address this directly in GES since we already pull up the group object during email sendouts. We could check if the group is hidden, if so, switch the link to use wp-login.php?redirect_to=LINK_TO_HIDDEN_GROUP_FORUM_TOPIC
.
I think this solves the problems mentioned here. What do you think?
Updated by Boone Gorges over 11 years ago
Ray - That sounds good. When a logged-in user attempts to access that URL, he'll be redirected right along to the group forum topic without having to log in, right?
Updated by Raymond Hoh over 11 years ago
When a logged-in user attempts to access that URL, he'll be redirected right along to the group forum topic without having to log in, right?
Just tested this briefly and it doesn't redirect for logged-in users. I thought it would! :(
I think I'll do a combination of what I suggested and what you suggested here.
Updated by Boone Gorges over 11 years ago
- Target version changed from 1.4.12 to 1.4.13
Updated by Raymond Hoh over 11 years ago
Boone, I've added a pull request to the GES repo for this issue.
Let me know what you think.
Updated by Boone Gorges over 11 years ago
- Target version changed from 1.4.13 to 1.4.14
Updated by Boone Gorges over 11 years ago
- Target version changed from 1.4.14 to 1.4.15
Updated by Boone Gorges over 11 years ago
- Target version changed from 1.4.15 to 1.4.16
Updated by Raymond Hoh over 11 years ago
- Status changed from Assigned to Resolved
Boone updated GES a few weeks ago so this should be resolved as of CAC 1.4.15.
Updated by Matt Gold almost 11 years ago
- Status changed from Resolved to Assigned
- Target version changed from 1.4.16 to 1.5
Just ran into this again while accessing a link to a doc in a private group. Screenshot attached.
Put this in 1.5, but please move it to 1.5.1 if needed.
Updated by Matt Gold almost 11 years ago
and here's that screenshot . . ..
Updated by Boone Gorges almost 11 years ago
This means that Docs emails need the same treatment as forum post emails. I'm not sure how smoothly this is going to work, because Docs emails are generated by the generic activity handling function, and I'm not sure at a glance whether we should extend the treatment to all group activity items. Ray, if you could chime in with your thoughts, that'd be great.
Updated by Raymond Hoh almost 11 years ago
In an ideal world, BuddyPress would handle private group access for all subpages and redirect the user to login if necessary. Hidden group pages are another matter altogether as discussed here.
As for BP Docs, do we want to do what we did with GES? Or should I write some custom code for CAC?
For new docs, I could probably filter "bp_docs_activity_args" to do what we need and piggyback off of the redirection code in GES to address this.
Likewise for comments on docs, I can filter "bp_docs_comment_activity_args".
Updated by Boone Gorges almost 11 years ago
In an ideal world, BuddyPress would handle private group access for all subpages and redirect the user to login if necessary. Hidden group pages are another matter altogether as discussed here.
Yes, it'd be nice for BP to be smarter about this, though as you note, it wouldn't be a truly general solution for our purposes, since the group notification issue applies to hidden groups as well as private groups. So I think this is a problem that has to be solved even aside from BP core.
I could probably filter "bp_docs_activity_args" to do what we need
You mean, to change the primary_link? I was thinking that this issue could be addressed in GES, by applying the wp-login.php trick in the general activity logger function https://github.com/boonebgorges/buddypress-group-email-subscription/blob/master/bp-activity-subscription-functions.php#L353 (so, basically a port of https://github.com/boonebgorges/buddypress-group-email-subscription/commit/c382771 to ass_group_notification_activity()
). Then we don't have to build anything Doc specific, and we'll automatically fix activity like bp-group-documents at the same time. What do you think?
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5 to 1.5.1
It's looking like we won't have this in place for the 1.5 release, so I'm moving it from the milestone.
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.1 to 1.5.2
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.2 to 1.5.3
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.3 to 1.5.4
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.4 to 1.5.5
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.5 to 1.5.6
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.6 to 1.5.7
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.7 to 1.5.8
Updated by Boone Gorges almost 11 years ago
- Target version changed from 1.5.8 to 1.5.9
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.9 to 1.5.10
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.10 to 1.5.11
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.11 to 1.5.12
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.12 to 1.5.13
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.13 to 1.5.14
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.14 to 1.5.15
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.15 to 1.5.16
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.16 to 1.5.17
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.5.17 to 1.6
Updated by Boone Gorges over 10 years ago
- Category name changed from WordPress (misc) to Email Notifications
Updated by Boone Gorges over 10 years ago
- Target version changed from 1.6 to 1.7
Updated by Boone Gorges almost 10 years ago
- Status changed from Assigned to Resolved
I'm no longer able to reproduce this issue. I wonder if it might just go away with later versions of BuddyPress Docs. I'm going to close the ticket - please feel free to reopen if it's still occurring after the 1.7 release.