Version: 1.9.0 (using KDE 4.6.3) OS: Linux When I try to upload a picture to facebook using KIPI plugin, it gives an error message "Facebook Call Failed: Application has been deleted". I also noticed that previously uploaded pictures that were uploaded using KIPI disappear from my facebook account. other pictures that were not uploaded using KIPI are displaying fine. Reproducible: Always Steps to Reproduce: try uploading a picture to facebook using KIPI plugin from a KIPI aware application (digikam, gwenview, etc) Actual Results: error message "Facebook Call Failed: Application has been deleted" Expected Results: picture get uploaded to facebook
Confirming the issue. Almost all my albums are gone. ~~ It says the application was deleted. Maybe facebook blacklisted the application?
Oh my... my pictures are gone as well. I tried to contact the developer of the application the other day, I hope that I didn't trigger this. :( An intermediate fix I could offer for 2.0.0 is to create a new application and use this one until we have resolved this (I hope it can be resolved, actually). That wouldn't bring any old pictures back, but at least allow uploading new ones again. If we manage to resolve this, we could switch back to the old application and leave this one dormant (so the pictures stay there). Gilles, is that okay? I will in the meantime try to contact Facebook and the developer (provided I can find out who it was) to see whether something can be done about it.
Okay, the registered developer was apparently kde-imaging@kde.org. I just found my attempted contact in my own mails.
Dirk, what's your FB account ? Anyway, your proposal is fine for me. I CC original FB tool author (Luka Renko) for info... Gilles Caulier
*** Bug 276627 has been marked as a duplicate of this bug. ***
Well before creating a new application, I'd like to know why the associated albums and photographs are gone. If facebook can decide to get rid of all content linked to a given uploading application without notice, it creates somehow some sort of problem on the long run...
That might have happened to us: http://forum.developers.facebook.net/viewtopic.php?id=103438
@Lure according to that thread on the FB forums there is an appeals process to get the app re-enabled and all the content uploaded by it will be restored. http://forum.developers.facebook.net/viewtopic.php?pid=355340#p355340 (/me hopes Lure reads his email, I take my FB baby photos very seriously)
http://bugs.developers.facebook.net/show_bug.cgi?id=18701 I hope I didn't put too many words in my bug report. ;)
Actually the case might be very valid in our case, because we ship the secret API key in the source code (fbtalker.cpp:79), which is just...well, wrong. I mean, anyone can take the key and pose as our KIPI Plugin, upload stuff, get marked as spam and there we go. But the question is, how else should this be handled on our side? We can't close the source and we need this keys present. Maybe use some encoding on them? I don't know..
Martin, I thought about this problem (distributing the private API key) in the source a few months ago. It is a problem with Facebook and with other services, and will be a problem with newer services. What we are doing is wrong according to their policies. The only solution that would abide by the policy of "do not distribute the private key in the source" I could come with is to have a KDE-wide server (for instance, appkeys.kde.org ) and have our applications send a request to that server that would return the private key. Granted, it is actually as insecure as distributing the key with the source, but at least would not violate Facebook's, Twitter's, etc policy so obviously.
I myself don't see any solution except asking the user to register an application id and keep it secret for his usage. This will multiplicate the number of application id that facebook will have for a single application. This means the application will be personnal and not fakable. Deletion based on reports should only affect the user using it. The problem is that it increases the difficulty for the user, as he has to register an api key for himself. For this solution to work, the code will mostly likely needs to be changed or adapted so an external application id and secret can be used. On facebook side, it would be a good thing if there could be a way to make uploads that are older than a given date like any others, not linked with an uploading application. If the content is safe and not infringing the facebook policy, there should be no reason for it to be deleted because the application was deleted.
I doubt it is the openness of our key that was the direct cause of the problem unless it was because of a spammer imitating kipi. There are a lot of photo apps mentioned in the FB forum thread linked above and I expect that many of them are not open source. I do think that we need to use more than one key though so that will lower the future exposure. Whether we need to go as far as one per user or just to one per application, I don't know.
So how does, for example, the Maemo FB photo upload work? It doesn't need an FB app.
*** Bug 276673 has been marked as a duplicate of this bug. ***
On 06/28/11 12:15, Pau Garcia i Quiles wrote: > I thought about this problem (distributing the private API key) in the source a > few months ago. > > It is a problem with Facebook and with other services, and will be a problem > with newer services. What we are doing is wrong according to their policies. As I have explained now in a couple of places: The kipi-plugins 2.0.0 have got its Facebook authentication upgraded to OAuth2. From this version on forward the only place where the secret is used at all is to convert the old authentication keys to OAuth2. That part could easily be removed, as it actually provides only minimal additional convenience. That said, consider that with OAuth2 authentication we don't need the secret anymore at all. And so, nobody does. Knowing our application ID, anyone could impersonate KIPI and ask the user for whatever permissions they like. As a matter of fact this is what I did when I upgraded the KIPI Facebook plug-in to OAuth2 authentication. The only technical means FB gives us to prevent that is to limit all requests to one IP (or a small subnet), but that as a desktop application this is not an option we can use. > The only solution that would abide by the policy of "do not distribute the > private key in the source" I could come with is to have a KDE-wide server (for > instance, appkeys.kde.org ) and have our applications send a request to that > server that would return the private key. > > Granted, it is actually as insecure as distributing the key with the source, > but at least would not violate Facebook's, Twitter's, etc policy so obviously. I wasn't aware of such a policy, could you please paste a link to it into this bug? If FB chooses to introduce keys in OAuth2 in client-mode, what we could do is: having kipi-plugins.org or digikam.org be a wrapper for the authentication. Instead of having the client authenticating directly, they'll send a request to kipi-plugins.org and we do the server handshake. Once the authentication is complete, we hand back the authentication token to the digikam app and from then on, the desktop app can do whatever it needs to.
Looks like the bug report got closed. They are saying to use the appeal form instead.
Wonderfull FB bug tracking... Gilles Caulier
(In reply to comment #17) > Looks like the bug report got closed. They are saying to use the appeal form > instead. Anyone has managed to contact Luka Renko? I can fill out that form, but I was worried that if I fill in different details than he did when he created the app, that things might turn to our disadvantage.
Dirk, I CC Luka Renko in this file. He must recieve a copy. I hope he will join us to help you in this task... Gilles Caulier
My albums and esby's albums have reappeared. Has any one of you of you been in contact with Facebook and received some communication regarding the reactivation of the app?
The "KDE KIPI Import/Export Plugin" has been reactivated, but I for one did not receive any reply to a issue report I had done regarding missing photos.
No me. Just for info, some words written on digiKam users ML : On Tuesday 28 June 2011 18:33:33 Marie-Noëlle Augendre wrote: > Thanks for the link. > I could always find another way to upload pictures to FB, but I'm very > disappointed that almost all the photos I have uploaded have disappeared As far as I know those pictures are not deleted but hidden. They will be visible again at the time the kipi-key for facebook is removed from the spam detection list. There is a page on this, but it is in German [1] and anther an English, but I have not read it [2]. Cheers, Wolfgang [1] http://www.pro-linux.de/news/1/17205/facebook-sperrt-digikamampco-aus.html [2] http://forum.developers.facebook.net/viewtopic.php?pid=355340#p355340 Gilles Caulier
I did not contact Facebook, because last time I tried this was just a farce. I informed some magazines about the fact --- Facebook needs a good reputation to be able to earn money by advertising. Stupidly hiding/blocking albums isn't what one expects to be something keeping reputation at a high level. But it is true: we'll shall get rid of the application on Facebook to upload pictures with digikam. There must be a way to make it work without it!
My albums and photos also reappeared. I tried contacting facebook using form in http://www.facebook.com/help/contact.php?show_form=photos_albums_missing but didn't get any reply other than 'thank you for submitting this bug report'
Questions : It's possible to load again photo through 1.9.0 release ? And with 2.0.0 RC, just released, it's work ? Gilles Caulier
(In reply to comment #26) > Questions : > > It's possible to load again photo through 1.9.0 release ? I can't test that currently, but many people reported having no problems and my guess is that the majority of them is using the stable version. > And with 2.0.0 RC, just released, it's work ? I did not test against the RC, but against the master branch and that worked fine. I close this bug for the time being as fixed by Facebook. Luka Renko, when you read this, please contact me.