Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

facebook: v2.0 api no longer allows lookup by username #350

Closed
snarfed opened this issue Jan 21, 2015 · 22 comments
Closed

facebook: v2.0 api no longer allows lookup by username #350

snarfed opened this issue Jan 21, 2015 · 22 comments
Assignees
Labels

Comments

@snarfed
Copy link
Owner

@snarfed snarfed commented Jan 21, 2015

...or at least, that's what we think so far. irc discussion. i'm still trying to find an explicit confirmation in their docs. the upgrade guide and platform changelog say the username field was removed from user objects in responses, but nothing about looking up by username.

the problem is that for users with usernames, FB redirects their posts to URLs that use their username instead of their id, e.g. https://www.facebook.com/snarfed.org/posts/10100929680893833 . you can look up and write to some FB posts (like that one) by bare post id, /10100929680893833, but not others, e.g. https://www.facebook.com/ben.werdmuller/posts/10101055597765779 vs /10101055597765779. we don't yet know what causes the difference.

the latter ones work if you prefix the user id, e.g. USERID_POSTID. (username prefix doesn't work.) so we'd need to do that for publish to like/comment on/share them. however, we can't get the user id, so we're hosed. :(

thanks to @kylewm for raising and pinpointing this.

@kylewm
Copy link
Collaborator

@kylewm kylewm commented Jan 22, 2015

Some dead ends...

  • /me/friends only contains other friends that have authorized the application in question (aside: kind of interesting to see which friends have done this for the API Explorer, mine were an FB employee, a political science researcher, and some general nerds)
  • /me/taggable_friends returns a full friends list but with "tokens" only usable for tagging, instead of their IDs
  • an unauthenticated call to https://graph.api.com/ben.werdmuller gives his global unique ID, but obviously not the app-scoped one we need.
@snarfed
Copy link
Owner Author

@snarfed snarfed commented Jan 23, 2015

here's a radical proposal: switch from the current POSSE model to PESOS. it would take a lot of work, but it would bring a lot of benefits.

...man oh man i wish i had the bandwidth right now to actually implement it!

@kylewm
Copy link
Collaborator

@kylewm kylewm commented Feb 1, 2015

So I think I've found a reliable (for now) way to find someone's app scoped user id, but I still can't find a way to access those posts via the API.

An unversioned, unauthenticated call to https://graph.facebook.com/stephanie.rodgers.980 gives their global user ID, then an unversioned, authenticated call to https://graph.facebook.com/4705326 gives a link to https://www.facebook.com/app_scoped_user_id/10100593893240028/

So, I have the user ID now: 10100593893240028. I had hoped that this would mean I could get {user_id}_{post_id} now, but no!

/v2.2/10100593893240028_10100777887638778
/v2.2/10100777887638778

both fail with the same error message.

{
  "error": {
    "message": "Unsupported get request. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api",
    "type": "GraphMethodException",
    "code": 100
  }
}
@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 1, 2015

so infuriating, huh? regardless, interesting, nice find.

i assume both calls are using the v1 api, since the URLs are unversioned. https://developers.facebook.com/docs/graph-api/reference/v2.1/user/ids_for_business might give us a v2.x alternative for the second part, but I suspect there's still no 2.x way to look up by username. sigh.

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 4, 2015

@kylewm and i have been discussing euthanizing facebook liking and commenting entirely. :(

i'm going to collect all the options here, no matter how crazy:

  • give up and turn off support for commenting and liking
  • post an SO question, include all of our research so far, and attach a big fat bounty
  • find a personal connection at facebook and ply them for information
  • detect the cases that won't work and report a nice error message saying we can't. not ideal, but maybe ok if those cases are pretty predictable.
  • scrape the global (non-app-scoped) user id from the profile page. interestingly, this works for both public and private profiles. an unauthenticated fetch of https://www.facebook.com/snarfed.org (public profile) includes 6 instances of 212038. an unauthenticated fetch of https://www.facebook.com/andigalpern (private profile) still includes one instance of her global user id. i expect the residual global user ids will gradually disappear from the html in both cases, though.
  • scrape the object id from the post's html. e.g. right now, an unauthenticated fetch of https://www.facebook.com/andigalpern/posts/678121182314631 doesn't have the object id 100003502653187_678121182314631 exactly, but it does have a number of instances with colon instead of underscore, 100003502653187:678121182314631.
@kylewm
Copy link
Collaborator

@kylewm kylewm commented Feb 4, 2015

scrape the global (non-app-scoped) user id from the profile page. e.g. right now, an unauthenticated fetch of https://www.facebook.com/snarfed.org includes 6 instances of 212038. i expect those will gradually disappear, but still.

This wouldn't help us would it? The global user ID doesn't seem to refer to anything inside the API (unless that person has signed up for bridgy prior to the switch to the new API).

@kylewm
Copy link
Collaborator

@kylewm kylewm commented Feb 4, 2015

And I think we should definitely post a question to SO either way... for posterity if nothing else. I'll donate 500 karma points or whatever to the bounty :)

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 4, 2015

i think we can still use the global user id, or at least get somewhere with it.

first, if i get a bridgy access token in the explorer and look up a global user id, e.g. https://developers.facebook.com/tools/explorer?method=GET&path=100000224384191 , that at least works. second, we just need a user id to attach to the object id to make a composite id that we can comment or like against, right? it seems like it should work. i know, fb api, yeah, right...but i'll try.

@kylewm
Copy link
Collaborator

@kylewm kylewm commented Feb 4, 2015

let me know if you have better luck than i did... with user id 1740230476, app scoped id 4494578659463, and post id 10200383182099046, all 3 variations fail :(

/v2.2/10200383182099046
/v2.2/1740230476_10200383182099046
/v2.2/4494578659463_10200383182099046

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 5, 2015

here's a bunch more research and observations. this is basically just fodder for an eventual stack overflow question; no really new information or conclusions, sadly.

a couple notes: the graph explorer links here use access tokens that include read_stream. other permissions too, but i think that's the critical one. i'm also going to be using users who haven't installed bridgy, which i think is important...? who knows. :/

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 5, 2015

yay, thank you! fingers crossed!

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 14, 2015

we've sadly concluded that our research here is correct, and the way forward is to shut down bridgy publish support for facebook likes and comments. sad day in indiewebland. :/

props and thanks to @kylewm for his help with this!

@julien51
Copy link

@julien51 julien51 commented Feb 15, 2015

This is so sad :(

@kylewm
Copy link
Collaborator

@kylewm kylewm commented Feb 15, 2015

@julien51 definitely a bummer, but just to be clear facebook backfeed and facebook publish for notes and articles both still work and show no signs of stopping :) there was some confusion about that in the channel yesterday.

@julien51
Copy link

@julien51 julien51 commented Feb 15, 2015

Ha! Indeed. But still, it upsets me when APIs are changed/removed unilaterally, but I guess there is a reason for using protocols, rather than APIs!

@petermolnar
Copy link

@petermolnar petermolnar commented Jul 24, 2015

If it helps, I'm using this to import comments/likes, but I do it by post:
https://github.com/petermolnar/keyring-reactions-importer/blob/master/importers/keyring-reactions-facebook.php

For me, it worked, but there are glitches.

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Jul 24, 2015

thanks @petermolnar! fortunately this bug only killed bridgy publish for FB. backfeed is still working fine.

@kylewm
Copy link
Collaborator

@kylewm kylewm commented Jul 24, 2015

hi @petermolnar thanks from me too :) it looks like you're using the /v2.2/USERID_POSTID format to find posts from syndication links. there's two problems that break this approach for bridgy:

  1. When replying to a random post on Facebook (e.g. to someone who does not use bridgy), we cannot (by design) find the other user's app-scoped ID
  2. USERID_POSTID doesn't work reliably, some post types or some users have a different format that is harder to guess
@snarfed
Copy link
Owner Author

@snarfed snarfed commented Jul 24, 2015

re #2, here's an example of code we use to try different id formats and merge the results (!) (😭): snarfed/granary@15b633e

@petermolnar
Copy link

@petermolnar petermolnar commented Jul 24, 2015

  1. When replying to a random post on Facebook (e.g. to someone who does not use bridgy), we cannot (by design) find the other user's app-scoped ID

I wasn't aware of this earlier but I've read the conversation since. This is genuine madness from Facebook.

  1. USERID_POSTID doesn't work reliably, some post types or some users have a different format that is harder to guess

I've noticed that, especially with pretty old entries, like 2009.

To be honest, I'm very close to the point to leave the whole sh*t behind, including Twitter with their ridiculously restricted API.

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Jul 24, 2015

huh. here's something interesting in the 2.4 API changelog (search for Declarative Fields):

To try to improve performance on mobile networks, Nodes and Edges in v2.4 requires that you explicitly request the field(s) you need for your GET requests. For example, GET /v2.4/me/feed no longer includes likes and comments by default, but GET /v2.4/me/feed?fields=comments,likes will return the data. For more details see the docs on how to request specific fields.

they've supported the fields param for a while, but afaik it was always optional for all edges before 2.4. bridgy uses 2.2, so it's probably not the root cause of us seeing partial objects...but who knows. plus we'll have to do it eventually anyway!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.