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

Comments

Projects
None yet
4 participants
@snarfed
Owner

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

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Jan 22, 2015

Collaborator

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.
Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Jan 23, 2015

Owner

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!

Owner

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

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 1, 2015

Collaborator

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
  }
}
Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Feb 1, 2015

Owner

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.

Owner

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Feb 4, 2015

Owner

@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.
Owner

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

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 4, 2015

Collaborator

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).

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 4, 2015

Collaborator

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 :)

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Feb 4, 2015

Owner

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.

Owner

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

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 4, 2015

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Feb 5, 2015

Owner

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. :/

Owner

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. :/

@kylewm

This comment has been minimized.

Show comment
Hide comment
@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Feb 5, 2015

Owner

yay, thank you! fingers crossed!

Owner

snarfed commented Feb 5, 2015

yay, thank you! fingers crossed!

@snarfed snarfed referenced this issue Feb 13, 2015

Closed

Double facebook #755

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Feb 14, 2015

Owner

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!

Owner

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

This comment has been minimized.

Show comment
Hide comment
@julien51

julien51 Feb 15, 2015

This is so sad :(

julien51 commented Feb 15, 2015

This is so sad :(

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 15, 2015

Collaborator

@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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@julien51

julien51 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!

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

This comment has been minimized.

Show comment
Hide comment
@petermolnar

petermolnar 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.

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Jul 24, 2015

Owner

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

Owner

snarfed commented Jul 24, 2015

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

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Jul 24, 2015

Collaborator

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
Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Jul 24, 2015

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@petermolnar

petermolnar 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.

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Jul 24, 2015

Owner

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!

Owner

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