GNOME Bugzilla – Bug 785726
facebook: Cannot add a new account with Graph API > 2.3
Last modified: 2017-08-06 02:13:10 UTC
Facebook retired version 2.3 of their Graph API on 8th July [1]. Current versions of the API no longer return a string field named "email" when a GET request is issued against https://graph.facebook.com/me with a valid OAuth2 access token. This breaks get_identity_sync and one cannot add a new Facebook account. If the Graph API Explorer [2] is pointed at https://graph.facebook.com/v2.10/me?metadata=1, then it sends: { "name": "Debarshi Ray", "metadata": { "fields": [ { "name": "id", "description": "The id of this person's user account. This ID is unique to each app and cannot be used across different apps. [Our upgrade guide provides more information about app-specific IDs](/docs/apps/upgrading/#upgrading_v2_0_user_ids)", "type": "numeric string" }, [...] { "name": "email", "description": "The person's primary email address listed on their profile. This field will not be returned if no valid email address is available", "type": "string" } ], }, "id": "...." } Now, my account does have a valid email address, and until version 2.3 was retired, it was returning an "email" member for me. A few other people on the Internet have encountered the same, but nobody seems to know why. [1] https://developers.facebook.com/docs/apps/changelog [2] https://developers.facebook.com/tools/explorer/
Since newer versions of the API no longer include the "username" member [*], I think we should fallback to "name", which is the human-readable name of of the user. However, it can't be used to log in via the embedded web view, so we can no longer pre-fill the form when refreshing the account. [*] Can't find any references
Created attachment 356773 [details] [review] facebook: Avoid CRITICALs if get_identity_sync can't parse the response
(In reply to Debarshi Ray from comment #0) > Now, my account does have a valid email address, and until version 2.3 was > retired, it was returning an "email" member for me. A few other people on > the Internet have encountered the same, but nobody seems to know why. Ok, I figure this out. I somehow convinced myself that the "email" scope/permission [1] was one of the default permissions, but it isn't. That's why the Graph API Explorer wasn't showing the "email" because it was not in the list of permissions for the explorer's access token. It started showing up when I changed the explorer to use an access token obtained by gnome-online-accounts. [1] https://developers.facebook.com/docs/facebook-login/permissions
Created attachment 356796 [details] [review] facebook: Avoid CRITICALs if get_identity_sync can't parse the response
Created attachment 356797 [details] [review] foursquare: Avoid CRITICALs if get_identity_sync can't parse response
Created attachment 356798 [details] [review] google: Avoid CRITICALs if get_identity_sync can't parse response
Created attachment 356799 [details] [review] lastfm: Avoid CRITICALs if lastfm_login_sync can't parse response
Created attachment 356800 [details] [review] oauth2: Avoid CRITICALs if get_tokens_sync can't parse response
Created attachment 356801 [details] [review] todoist: Avoid CRITICALs if get_identity_sync can't parse response
Created attachment 356802 [details] [review] live: Avoid CRITICALs if get_identity_sync can't parse response
Created attachment 356803 [details] [review] flickr: Avoid CRITICALs if get_identity_sync can't parse response
Created attachment 356804 [details] [review] facebook: Make it work with Graph API > 2.3
CCing Thomas because the fallback he added in bug 739168 had to be removed (see attachment 356804 [details] [review]). I don't know what the replacement would be, and if one is even possible or desired.
Created attachment 356805 [details] [review] facebook: Update README
Created attachment 356808 [details] [review] facebook: Make it work with Graph API > 2.3
Created attachment 356862 [details] [review] lastfm: Avoid CRITICALs if check_cb can't parse response
*** Bug 785666 has been marked as a duplicate of this bug. ***