Project

General

Profile

Bug #3134

Bad link in "mentioned you in an update" email

Added by Michael Mandiberg almost 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
BuddyPress (misc)
Target version:
Start date:
2014-03-25
Due date:
% Done:

0%

Estimated time:

Description

The automatic "mention" email included a link that redirected to Jorge Matos' profile

"@mandiberg – In regards to “blogging as a skill,” I’m referencing the writing of a blog vs. a paper vs. any other assignment. I think in academia we reinforce and […]"

To view and respond to the message, log in and visit: http://commons.gc.cuny.edu/activity/p/261547/

When I clicked on that link, it took me here: http://commons.gc.cuny.edu/members/jmatos/activity/261507/

I have not received any other notices recently, so I can't tell if this is a one-time error, or repeatable.

History

#1 Updated by Matt Gold almost 8 years ago

  • Category name set to BuddyPress (misc)
  • Status changed from New to Assigned
  • Assignee set to Boone Gorges

Thanks for reporting, Michael!

#2 Updated by Michael Mandiberg almost 8 years ago

The plot thickens: I got another update, and paid closer attention this time. I am getting four updates. Two http and two https. All with different URLS. Posted here in order of receipt:

To view and respond to the message, log in and visit: http://commons.gc.cuny.edu/activity/p/261785/
To view and respond to the message, log in and visit: http://commons.gc.cuny.edu/activity/p/261790/
To view and respond to the message, log in and visit: https://commons.gc.cuny.edu/activity/p/261879/
To view and respond to the message, log in and visit: https://commons.gc.cuny.edu/activity/p/261869/

#3 Updated by Matt Gold almost 8 years ago

  • Severity set to High impact

Hi Michael -- were these new notifications related to new mentions/activity events?

#4 Updated by Michael Mandiberg almost 8 years ago

The four notifications were all related to one new mention. So I guess it was a new mention /once/ and was an old mention for the other three.

#5 Updated by Matt Gold almost 8 years ago

Hi Michael,

FYI, we're nearing the end of a dev cycle, so our team is a little less available for bug issues than it normally is. We will get to this, but while you're waiting, can you please update this ticket if this occurs again? Thanks.

#6 Updated by Michael Mandiberg almost 8 years ago

will do.

#7 Updated by Boone Gorges almost 8 years ago

  • Target version set to 1.5.22

I've spent a bunch of time trying to trace this down, and I think I've got it mostly put together. Michael, feel free to skip to the tl;dr - I'm writing this all out for posterity.

==
A number of groups on the Commons are using the External Blogs tool to specify RSS feeds that should be pulled into their blogs' activity feeds. Usually this works fine. But in a few cases, the group admins have entered the URL of a Commons RSS feed that is not publicly viewable, such as that associated with a private group; when you pull up the feed URL in a browser (as a logged-out user), you get a login page asking you to log in to view the content. The URLs look like this: http://commons.gc.cuny.edu/groups/questionpointatcuny/feed/. The external blogs plugin uses WP's RSS-fetching library, which essentially sends a cURL request to the URL in question - the virtual equivalent of an un-logged-in user. However, instead of redirecting to the login page (like a normal browser agent would be), WP recognizes that this is an RSS agent, and tries to be clever by finding a similar feed URL that is available. In this case, it settles on http://commons.gc.cuny.edu/activity/feed/ - the sitewide feed.

Now, it just so happens that during one of these fetches, some comments from the ITP Core 2 public blog had been posted to the sitewide activity stream; furthermore, it so happens that all of them had a mention of @mandiberg. When the items were reposted to the offending group, notifications were (correctly) sent to Michael to notify him of new mentions. In other words, the URLs that Michael got in the emails all correspond to actual, separate activity mentions that happened in blog comments on the ITP Core 2 blog - I've cross-referenced all the activity IDs from the URLs that Michael has shared above.

The problem with the incorrect redirects lies in BP's activity permalink router. The activity items are stored as type 'exb' ("external blog"). They are associated with the 'groups' component, and in particular with the offending group described above. They are not associated with any individual user (because the external blogs plugin assumes that the feeds come from non-members). BP doesn't natively know how to route activity items that don't have user_ids associated with them, but we have some custom functionality on CAC that routes these items to their "primary_link" attribute. And it appears that there is a bug in the external blogs plugin that incorrectly sets the 'primary_link' of the activity items corresponding the fetched items to the RSS primary link of the final item in the list. In this case, it happened to be a group-join by Jorge Matos. Thus the redirect.

tl;dr
So, in sum, in addition to a sorta bizarre combination of normal behaviors on the site, a couple bugs are conspiring to cause the observed behavior:
1. Some group admins have inadventently entered external blog feeds that are not actually accessible to our RSS fetching mechanisms
2. There's a bug in the external blogs plugin that causes primary_link values to be set incorrectly

I'll make some interim fixes for each issue.

#8 Updated by Boone Gorges almost 8 years ago

In https://github.com/castiron/cac/commit/5dd5e21ad0d0600c81d8b3a117b3516eb7c17bf1 I fix the bug with the improper primary_link value

In https://github.com/castiron/cac/commit/83603ebfbf4ee923e7f533515c32d48ce2770800 I run some sanity checks on the "feed" URLs entered by users - I fetch it, and then see if it's parseable as XML, and bail if it's not.

Got one more fix coming up, this one for the routing problem.

#9 Updated by Boone Gorges almost 8 years ago

  • Status changed from Assigned to Resolved

Actually, on examination, I'm not going to try to patch the routing issue. BP's router was really acting properly in this case, given the faulty information that it had. If the primary_link value had been correct, you'd've been redirected to the activity item within the context of the offending group; while annoying (your post never should have been aggregated there in the first place), this would have been the correct behavior. The previous two fixes should prevent further instances of this kind of problem.

I'm going to mark the issue as resolved, given the above discussion. Michael, the activity links you've shared above will continue to be inaccessible (they'll route incorrectly) but you should not get any more items like this in the future. If you do, please post an update here. Thanks.

#10 Updated by Michael Mandiberg almost 8 years ago

Epic status update! Thanks for the td;dr, and well done.

#11 Updated by Matt Gold almost 8 years ago

+1: this is a tour-de-force. Thank you so much for your careful attention to this ticket and your great write-up of the issues involved, Boone.

Also available in: Atom PDF