GNOME Bugzilla – Bug 748991
Error to publish on Facebook
Last modified: 2016-06-15 06:34:38 UTC
Hello I'm got a error when publishing some photos with Shotwell 0.20.2 on Ubuntu 15.04. At first the albums are not loading and the screen just refresh if you try to create a new album. Everything was working last week. It's looks like a permission error on the Shotwell facebook app, because Shotwell just requested Public profile data. To Reproduce: 1 - Select a photo 2 - Click on Publish button 3 - Log in on the Facebook 4 - Albums are not loaded 5 - Try to publish 6 - The screen get back to the select album screen Already tried: - Re-install Shotwell - Install 0.22 and try to publish ( The same problem and don't recognize the Ubuntu Accounts ) - Remove and add again Shotwell permission on facebook - Remove and add again Facebook Account
I can confirm this "misconfiguration" of the FB app (ID 162702932093). If I publish photos with shotwell using my own app ID everything works fine. This is hardly a practical workaround though, so please fix this soon. Thanx, Ezra.
Created attachment 303181 [details] Facebook entry in Online Accounts
I have the same symptoms as Julio see also https://bugzilla.gnome.org/show_bug.cgi?id=748991#c2 with a screenshot of Facebook entry in Online Accounts
When I attempt to publish to facebook, I am informed I'm not currently logged in to facebook. I follow the prompts to log in and try again to publish, I am then offered only the 'shotwell connect' album with no access to any others. When I go ahead to publish, I am informed that I have already logged in and out in this session and to quit shotwell and restart and try again. When I do this, the entire process repeats. I have tried a complete hard reset, reinstallation, and changing the order in which I start shotwell and facebook. Shotwell 0.20.2 Firefox 37.0.2 Mozilla Firefox for mint mint - 1.0 Linux mint 17 Qiana Kernel 3.13.0-24-generic MATE 1.8.1
Yes, we all have the same symptoms. Shotwell does not seem to have the permission to access the photo albums. Please do not waste more time on trying to solve the problem locally (your computer). If it were possible I would submit a patch but I guess this is a case where even the open source software user's hands are tied. Or are the Facebook login credentials published somewhere? Some Shotwell developer (Lucas Beeler?) that knows the credentials must login to https://developers.facebook.com/apps/ and revise the configuration. Or give me the credentials and I will do it...
I guess the problem lies here: From https://developers.facebook.com/docs/apps/api-v1-deprecation/: At F8 in 2014, we announced Graph API v2.0 and our plans to deprecate v1.0 one year later on April 30th, 2015. Starting April 30th, we'll begin to: (...) Require Login Review for all apps that use Facebook Login and ask people for permissions other than email, public_profile or user_friends. Any permissions that haven't been reviewed and approved will no longer show in the Login dialog and apps can't access, ask for, or be granted them. (...) So if not already, following must be done: https://developers.facebook.com/docs/facebook-login/review/how-to-submit
Notably from #748847: > Chris H 2015-05-16 08:19:40 UTC > I notice too that clicking on the "Shotwell Connect" credit from an earlier > successfully published album takes me to > https://www.facebook.com/games/?app_id=162702932093&pnref=story which > declares > > "Misconfigured App > Sorry, Shotwell Connect hasn't been approved for display in App Centre."
Just for clarity: while this bug has been found in Ubuntu, it doesn't seem to be specific to the Online Accounts integration which we have in Ubuntu. The Ubuntu-specific part of the bug is being tracked at https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1453549 But in any case, to have Facebook working in Shotwell something must be done with the "Shotwell Connect" application in the Facebook site.
As spoke in comment #8, I have the same issue on Debian Jessie (shotwell 0.20), and persisted in Fedora 22 (shotwell 0.22)
Created attachment 303861 [details] Error message in Fedora 22
I believe this step is missing from the old Facebook Graph API used in shotwell (I think ti's the v1.0) to the current (v2.3) one: "Inspecting access tokens": https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.3#checktoken
News: the (empty) album list generated by calling the Facebook Graph API (with the access token got by the application) have the debug message: "The field 'albums' is only accessible on the User object after the user grants the 'user_photos' permission."
Complementing the comment #11, from https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.3#confirm: "[...] Confirming identity Because this redirect flow involves browsers being redirected to URLs in your app from the Login dialog, traffic could directly access this URL with made-up fragments or parameters. If your app assumed these were valid parameters, the made-up data would be used by your app for potentially malicious purposes. As a result, your app should confirm that the person using the app is the same person that you have response data for before generating an access token for them. Confirming identity is accomplished in different ways depending on the response_type received above: [...] * When token is received, it needs to be verified. You should _make an API call to an inspection endpoint_ that will indicate who the token was generated for and by which app. You can do this from the client or from the server, depending on your use case. [...]" ... and from "make an API call to an inspection endpoint" link (https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.3#checktoken, mentioned in the comment #11): "[...] This endpoint takes the following parameters: [...] access_token: An app access token or an access token for a developer of the app. [...]"
I am using Fedora 22. I deleted the shotwell database from my hidden files for a refresh, no avail. I also created a temporary account on my system, no avail there either. I get the message either way as described in comment #10.
This is still an issue on Ubuntu 15.04. I'm aware this is a configuration error with the FB app, not something specific to the plugin. Are the person(s) with access to the app's dev portal aware of the problem? Is there an ETA to fix it?
I like to have an estimated date to fix but, up to where I know, there isn't one (and the fix seem to be simple!)...
I am unable to pull up the app via Facebook developer tools to even just view the project. All I can suggest is having an active developer of shotwell contact Facebook to recover access to the project development area. Another alternative is to create the Facebook app from scratch. And also, there needs to be a way to do recovery more easily regardless of the approach to regain developer access.
*** Bug 748847 has been marked as a duplicate of this bug. ***
Hello Everyone, As of today's date, on my end (Ubuntu 14.04), NONE of the following apps are able to publish to FB: Shotwell, gThumb, digiKey, F-Spot. Thanks, :Dan
Hi all! I tried to get in touch with Yorba about the facebook key, but so far I didn't get a reply from them. So I went on and created another Facebook key for Shotwell, and we'll be using that key in Ubuntu (by applying a distro patch to Shotwell). Any other linux distribution is welcome to use the same key: 1612018629063184 Also, if someone with commit access to the Shotwell git repository could use this key instead of the old one (by changing line 60 of plugins/shotwell-publishing/FacebookPublishing.vala), that would be very welcome. Currently the key is registered under my personal Facebook account. I'd be happy transfer the ownership of the key to a group of people trusted by Yorba or by the GNOME community.
Shotwell could share the Facebook API keys with GNOME Online Accounts. See https://wiki.gnome.org/Initiatives/OnlineServicesAPIKeys
The probem still exists!
If you mean that the people governing the Facebook key for Shotwell should be the same people governing the Facebook keys for GNOME Online Accounts, that's quite fine. But if you mean that there should be a single application key used both for Shotwell and GNOME Online Accounts, then I disagree. The Shotwell application key in facebook should clearly be named after Shotwell, carry its icon, and request only those permissions that are needed for Shotwell's functionality.
Please note that it is critically important that we fix bug #754488, request a CVE, and instruct users to change their Facebook passwords before we reenable this feature.
Also I think it's fine to have a separate Shotwell API key, since Shotwell doesn't use g-o-a. (Thanks for working on this Mardy!) But Shotwell should really support g-o-a and use it rather than its own API key when running in GNOME. I know Shotwell is unmaintained and this is not going to change, but it has to be said....
*** Bug 756350 has been marked as a duplicate of this bug. ***
If I'm not mistaken, aren't users already exposed to #754488 even with this feature broken?
(In reply to Jeremy Nickurak from comment #27) > If I'm not mistaken, aren't users already exposed to #754488 even with this > feature broken? You are right, Jeremy. In Ubuntu we don't have this problem because we patch Shotwell to use Ubuntu Online Accounts, but other distributions should indeed completely disable the Facebook plugin.
(In reply to Jeremy Nickurak from comment #27) > If I'm not mistaken, aren't users already exposed to #754488 even with this > feature broken? Yes, they are.
This bug blocks the following bug on Fedora/Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1224562
*** Bug 760342 has been marked as a duplicate of this bug. ***
(In reply to Michael Catanzaro from comment #25) > Also I think it's fine to have a separate Shotwell API key, since Shotwell > doesn't use g-o-a. (Thanks for working on this Mardy!) But Shotwell should > really support g-o-a and use it rather than its own API key when running in > GNOME. I know Shotwell is unmaintained and this is not going to change, but > it has to be said.... Will be on the roadmap to 0.24 (while trying not to disturb UOA integration) Thats on my map.(In reply to Michael Catanzaro from comment #24) > Please note that it is critically important that we fix bug #754488, request > a CVE, and instruct users to change their Facebook passwords before we > reenable this feature. I see your CVE request was unanswered but you got the DWF-2016-89001 - is there anything else to do from my side than to get a release out with the changes ASAP?
Yay, glad to see a new maintainer for Shotwell! (In reply to Jens Georg from comment #32) > I see your CVE request was unanswered but you got the DWF-2016-89001 - is > there anything else to do from my side than to get a release out with the > changes ASAP? Nothing else; I handled notifying distros a couple months ago. Though it would be good to test to make sure the WebKit upgrade did not break photo uploading for particular services... we've had this patch in Fedora 22 and Fedora 23 for months without complaints, and it just shipped in Ubuntu 16.04, but that doesn't necessarily mean there are no regressions.
(In reply to Michael Catanzaro from comment #33) > Yay, glad to see a new maintainer for Shotwell! > > (In reply to Jens Georg from comment #32) > > I see your CVE request was unanswered but you got the DWF-2016-89001 - is > > there anything else to do from my side than to get a release out with the > > changes ASAP? > > Nothing else; I handled notifying distros a couple months ago. > > Though it would be good to test to make sure the WebKit upgrade did not > break photo uploading for particular services... we've had this patch in > Fedora 22 and Fedora 23 for months without complaints, and it just shipped > in Ubuntu 16.04, but that doesn't necessarily mean there are no regressions. Well, it's only used for Facebook and Yandex. FB is broken anyway. Yandex didn't work in the old version. so it's safe to ship.
(In reply to Mardy from comment #20) > Hi all! I tried to get in touch with Yorba about the facebook key, but so > far I didn't get a reply from them. > So I went on and created another Facebook key for Shotwell, and we'll be > using that key in Ubuntu (by applying a distro patch to Shotwell). Any other > linux distribution is welcome to use the same key: 1612018629063184 > > Also, if someone with commit access to the Shotwell git repository could use > this key instead of the old one (by changing line 60 of > plugins/shotwell-publishing/FacebookPublishing.vala), that would be very > welcome. Just to recapitulate: You are perfectly fine with me commiting this to the shotwell git, yes?
(In reply to Jens Georg from comment #35) > Just to recapitulate: You are perfectly fine with me commiting this to the > shotwell git, yes? Yes Jens, please go ahead. Also, please write me your facebook username or numeric ID, so that I can add you as an admin for this application: if the needs comes to make some updates (facebook requires that from time to time), the more trusted people we have managing the app, the better.
*** Bug 767217 has been marked as a duplicate of this bug. ***
As far as Fedora is concerned, versions 22 and above of Fedora have shotwell 0.23.1 available in the updates repositories.
@Kevin How can you activate the update repo? I still have version 0.22.0.
If you are using Fedora 22 or later, the dnf utility can be used to get 0.23.1. Try: su --command="dnf update shotwell" The command requires the root password, and will update shotwell. If you omit the word shotwell, however, dnf will download and install all the available updates. If you choose to update the whole system this way, I do recommend that you go into a text terminal (ctrl+alt+F3 for tty3, for example). Use your root login, and the "dnf update" command will download and install the updates from the update repo. Be sure to use the command "reboot" once dnf is done.
I get this: >dnf update shotwell Error: Failed to synchronize cache for repo 'updates'
I looked up the issue in comment 41, and found some additional information on the Red Hat bugzilla that might help. I am leaving this bug as resolved as it appears the remainder of the comments starting on comment 38 are distro issues.