|Summary:||FaceBook export doesn't work any more due to bad url given back to register to before photo uploading|
|Component:||Plugin-WebService-Facebook||Assignee:||Digikam Developers <digikam-bugs-null>|
|Severity:||normal||CC:||caulier.gilles, davidpjames, didier.garde, dreibh, ed.shornock, futurepilot, juan.baptiste, kde, malinkh, pbhj, radiostermino, rick, shouryasgupta, sylvainsjc|
|Latest Commit:||http://commits.kde.org/kipi-plugins/946a4ed104c954f532efc27061a740b9904e317d||Version Fixed In:||4.12.0|
Description tps 2013-05-03 05:06:58 UTC
kipiplugins for Facebook doesn't give back an usable URL for communication and access to facebook picture upload. The given URL is something like "https://www.facebook.com/connect/blank.html#_=_". Unclear if this is a problem on Facebook or one because kipi-plugins do not handle given data korrektly. Reproducible: Always Steps to Reproduce: 1. Change your password on Facebook 2. Register Digicam again for uploading (the old URL is invalidated by password change) 3. Notice not given a new, usable URL Actual Results: URL handled not usable Expected Results: Usable URL Maybe a problem on Facebook, not Digicam
Comment 1 Thomas Dreibholz 2013-05-19 21:01:43 UTC
I can confirm the problem for the latest version of the kipi-plugins installed with Ubuntu 13.04: $ apt-show-versions | grep kipi kipi-plugins/raring uptodate 4:3.1.0-0ubuntu1 kipi-plugins-common/raring uptodate 4:3.1.0-0ubuntu1 libkipi-data/raring uptodate 4:4.10.2-0ubuntu1 libkipi10/raring uptodate 4:4.10.2-0ubuntu1 The URL returned is always https://www.facebook.com/connect/blank.html#_=_ (i.e. invalid for kipi plugins authentication).
Comment 2 Thomas Dreibholz 2013-05-22 20:15:58 UTC
When clicking on the KIPI Plugin in Facebook's App Center, it reports "This application does not yet support secure browsing (HTTPS)". It seems that Facebook has changed its API to make HTTPS mandatory, and the kipi plugin do not support HTTPS yet.
Comment 3 Rick 2013-05-29 02:44:54 UTC
I can confirm it is just as Thomas says, Using Ubuntu 13.04 with Chrome as the browser.
Comment 4 pbhj 2013-06-13 15:11:09 UTC
Same for me using 4:3.2.0-0ubuntu1~ubuntu13.04~ppa1.
Comment 5 pbhj 2013-06-17 16:25:46 UTC
Seems that it's going to the right page and then moving on to a generated page, perhaps a return from FB. You can get the correct URL - with the required token - by looking back in your history (just hitting back in the browser tab may work, not sure). See http://alicious.com/export-to-facebook-digikam-workaround/ for details of the workaround.
Comment 6 tps 2013-06-17 19:21:52 UTC
Yes, this is the workaround. But: it does not work with all browsers. I've tested. It works for - Firefox (sometimes the intermediate URL finds its way into the history list) - Opera (old stable - sometimes the redirect doesn't work as expected) It does not work for - Firefox (nightly - the intermediate URL is never entered into the history list) - Chromium, Chrome (same as with FF-Nightly) - Opera (actual stable - same as with FF-Nightly) I even tried lynx and others: they never get that far, because of java-script.
Comment 7 tps 2013-06-17 19:38:16 UTC
I tested again this moment: the latest nightly of chromium browser enters the intermediate URL into the history list! Means: the workaround works with this version too.
Comment 8 Thomas Dreibholz 2013-07-04 18:34:53 UTC
The workaround also works with Firefox 22.0 (Ubuntu, 64 bit).
Comment 9 tps 2013-07-05 04:18:19 UTC
Works for all browsers keeping a detailed history: - Chrome - Chromium - Firefox (all supported versions) - Opera - Konqueror
Comment 10 Christoph Feck 2013-07-21 12:05:14 UTC
*** Bug 319573 has been marked as a duplicate of this bug. ***
Comment 11 David P James 2013-08-09 21:07:56 UTC
The workaround (which I discovered independently of this bug) also works in rekonq - you have to open up the History page (Ctrl+H) and then Right-click -> Copy Link over the "login_success.html" entry. (I had about a dozen in the list, which I promptly deleted, due to futile attempts to stop the redirect).
Comment 13 caulier.gilles 2013-08-15 08:42:09 UTC
*** Bug 318967 has been marked as a duplicate of this bug. ***
Comment 14 ed.shornock 2013-08-15 14:05:11 UTC
(In reply to comment #12) > https://bugs.kde.org/show_bug.cgi?id=318967 may be a dupe. Yes...though that other bug was older. :P
Comment 15 Jay Armstrong 2013-10-21 07:55:23 UTC
*** This bug has been confirmed by popular vote. ***
Comment 16 caulier.gilles 2015-05-19 10:56:52 UTC
This file still valid using last kipi-plugins 4.10.0 ? Gilles Caulier
Comment 17 caulier.gilles 2015-05-19 11:24:24 UTC
*** Bug 320935 has been marked as a duplicate of this bug. ***
Comment 18 tps 2015-05-19 12:56:46 UTC
Yes, this is still valid. At least with browsers: - Chrome (waterfall, unstable, testing, stable) -> war: use url stored in history to reload page, then url to use with digikam is in history - Chromium (waterfall, unstable, stable) -> war: use url stored in history to reload page, then url to use with digikam is in history - firefox (nightly, alpha, beta, stable, esr) -> war: use url stored in history - Opera (testing, release) -> war: switch Opera to debug mode. Redirecting URL is the one to copy to digikam. - konqueror (release) -> did not find a way to get the URL to use with digiKam. The crude problem is Facebook: after login they send the URL to copy to digiKam, together with a page redirecting to an unusable URL. The time before redirecting is set to an incredible low value -- no time to copy the URL. Some browsers put these redirects into history (firefox), some do not (Chrome, Chromium, Opera, konqueror). But all put the URL called after entering User/Password into history -> calling this URL again enters the redirected URL into history for all browsers except konqueror.
Comment 19 caulier.gilles 2015-07-03 21:46:07 UTC
To comment #2 : No. plugin use HTTPS in source code since a while. The problem is in another place... Gilles Caulier
Comment 20 caulier.gilles 2015-07-03 21:48:37 UTC
Following comment #18, what's will be the solution here. It's sounds like a problem from FaceBook authentification service. No ? Gilles Caulier
Comment 21 tps 2015-07-04 12:28:27 UTC
The page facebook answers with is something like: "https://www.facebook.com/connect/login_success.html#access_token=CAA...." Facebook has a redirect within his header directing to "https://www.facebook.com/connect/blank.html#_=_". The redirect timeout is set to the minimum possible. The page tries to copy the URL handled back to your clipboard, but most browsers nowadays do not allow this action -- or replace the copied URL by the redirected URL. The only way to find the correct URL to copy is to look into your browsers complete history. Since some browsers do not hold such a history your lost with them. If your browser has a history keeping redirects also, you may copy the URL there. It is the right one to use with facebook export. Using this URL now gives the error: "User must specify a valid extended permission or data permission (100)". Meaning: connected OK, but didn't have permission to do what it wanted to do. Since there is AFAIK no way to specify the extended permission or data permission facebook export is asking for you are lost (if there was, it would be nice to have a link on some description on how to change and allow what is needed to make facebook export run!).
Comment 22 caulier.gilles 2015-07-04 12:32:05 UTC
Tps, yes the error message from Facebook is fully reproducible here... Note : FB sounds like more and more unsuitable in time... This is why i don't use it since a while (Thanks G+) Gilles Caulier
Comment 23 Shourya Singh Gupta 2015-07-21 10:38:07 UTC
Git commit 946a4ed104c954f532efc27061a740b9904e317d by Shourya Singh Gupta. Committed on 21/07/2015 at 10:37. Pushed by shouryasinghgupta into branch 'master'. Facebook up and running now Related: bug 240254, bug 289256, bug 347194 FIXED-IN: 4.12.0 A +638 -0 0001-Testing-Youtube-integration.patch M +4 -1 facebook/fbwindow.cpp http://commits.kde.org/kipi-plugins/946a4ed104c954f532efc27061a740b9904e317d
Comment 24 Shourya Singh Gupta 2015-07-21 10:42:50 UTC
Unwanted file 0001-Testing-Youtube-integration.patch that got added in this commit was removed in the next commit.