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
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).
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.
I can confirm it is just as Thomas says, Using Ubuntu 13.04 with Chrome as the browser.
Same for me using 4:3.2.0-0ubuntu1~ubuntu13.04~ppa1.
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.
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.
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.
The workaround also works with Firefox 22.0 (Ubuntu, 64 bit).
Works for all browsers keeping a detailed history: - Chrome - Chromium - Firefox (all supported versions) - Opera - Konqueror
*** Bug 319573 has been marked as a duplicate of this bug. ***
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).
https://bugs.kde.org/show_bug.cgi?id=318967 may be a dupe.
*** Bug 318967 has been marked as a duplicate of this bug. ***
(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
*** This bug has been confirmed by popular vote. ***
This file still valid using last kipi-plugins 4.10.0 ? Gilles Caulier
*** Bug 320935 has been marked as a duplicate of this bug. ***
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.
To comment #2 : No. plugin use HTTPS in source code since a while. The problem is in another place... Gilles Caulier
Following comment #18, what's will be the solution here. It's sounds like a problem from FaceBook authentification service. No ? Gilles Caulier
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!).
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
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
Unwanted file 0001-Testing-Youtube-integration.patch that got added in this commit was removed in the next commit.