319252 2013-05-03 05:06:58 +0000 FaceBook export doesn't work any more due to bad url given back to register to before photo uploading 2023-05-10 05:46:01 +0000 1 1 2 Applications digikam Plugin-WebService-Facebook unspecified Ubuntu Linux RESOLVED FIXED NOR normal --- 1 tps digikam-bugs-null caulier.gilles davidpjames didier.garde dreibh ed.shornock juan.baptiste kde malinkh nickbryda pbhj radiostermino rick shouryasgupta sylvainsjc http://commits.kde.org/kipi-plugins/946a4ed104c954f532efc27061a740b9904e317d 4.12.0 71 oldest_to_newest 1365895 0 tps 2013-05-03 05:06:58 +0000 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 1369864 1 dreibh 2013-05-19 21:01:43 +0000 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). 1370499 2 dreibh 2013-05-22 20:15:58 +0000 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. 1371959 3 rick 2013-05-29 02:44:54 +0000 I can confirm it is just as Thomas says, Using Ubuntu 13.04 with Chrome as the browser. 1376409 4 pbhj 2013-06-13 15:11:09 +0000 Same for me using 4:3.2.0-0ubuntu1~ubuntu13.04~ppa1. 1377455 5 pbhj 2013-06-17 16:25:46 +0000 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. 1377506 6 tps 2013-06-17 19:21:52 +0000 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. 1377511 7 tps 2013-06-17 19:38:16 +0000 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. 1381373 8 dreibh 2013-07-04 18:34:53 +0000 The workaround also works with Firefox 22.0 (Ubuntu, 64 bit). 1381469 9 tps 2013-07-05 04:18:19 +0000 Works for all browsers keeping a detailed history: - Chrome - Chromium - Firefox (all supported versions) - Opera - Konqueror 1385003 10 cfeck 2013-07-21 12:05:14 +0000 *** Bug 319573 has been marked as a duplicate of this bug. *** 1388802 11 davidpjames 2013-08-09 21:07:56 +0000 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). 1389861 12 pbhj 2013-08-15 02:42:44 +0000 https://bugs.kde.org/show_bug.cgi?id=318967 may be a dupe. 1389918 13 caulier.gilles 2013-08-15 08:42:09 +0000 *** Bug 318967 has been marked as a duplicate of this bug. *** 1389979 14 ed.shornock 2013-08-15 14:05:11 +0000 (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 1404932 15 jay 2013-10-21 07:55:23 +0000 *** This bug has been confirmed by popular vote. *** 1520137 16 caulier.gilles 2015-05-19 10:56:52 +0000 This file still valid using last kipi-plugins 4.10.0 ? Gilles Caulier 1520163 17 caulier.gilles 2015-05-19 11:24:24 +0000 *** Bug 320935 has been marked as a duplicate of this bug. *** 1520204 18 tps 2015-05-19 12:56:46 +0000 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. 1529994 19 caulier.gilles 2015-07-03 21:46:07 +0000 To comment #2 : No. plugin use HTTPS in source code since a while. The problem is in another place... Gilles Caulier 1529995 20 caulier.gilles 2015-07-03 21:48:37 +0000 Following comment #18, what's will be the solution here. It's sounds like a problem from FaceBook authentification service. No ? Gilles Caulier 1530147 21 tps 2015-07-04 12:28:27 +0000 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!). 1530150 22 caulier.gilles 2015-07-04 12:32:05 +0000 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 1532634 23 shouryasgupta 2015-07-21 10:38:07 +0000 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 1532639 24 shouryasgupta 2015-07-21 10:42:50 +0000 Unwanted file 0001-Testing-Youtube-integration.patch that got added in this commit was removed in the next commit. 2229181 25 caulier.gilles 2023-05-10 05:46:01 +0000 *** Bug 319573 has been marked as a duplicate of this bug. ***