Project

General

Profile

Bug #11640

Flickr integration is broken

Added by Nick Kachulin over 2 years ago. Updated 5 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
06/06/2017
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.2.5
System:
other GNU/Linux
bitness:
64-bit
hardware architecture:
amd64/x86

Description

It seems that flickr has changed its API.
Attempt to authorize darktable opens home page instead of authorization page as it used to be.

oauth_ini.diff (1.84 KB) oauth_ini.diff Stefan Schöfegger, 11/29/2017 10:44 PM
0001-flickr-switch-to-oauth-authentication.patch (45 KB) 0001-flickr-switch-to-oauth-authentication.patch jean-luc Le Corre, 06/19/2019 09:47 AM
0002-flickr-fix-large-file-and-no-password-backend.patch (5.17 KB) 0002-flickr-fix-large-file-and-no-password-backend.patch jean-luc Le Corre, 06/22/2019 10:45 PM
0003-flickr-fix-ui-storage.patch (15.1 KB) 0003-flickr-fix-ui-storage.patch jean-luc Le Corre, 06/24/2019 10:07 AM

Related issues

Related to darktable - Bug #10861: Flickr log in Duplicate01/07/2016

Has duplicate darktable - Bug #11759: flickr authentication brokenDuplicate10/05/2017

History

#2 Updated by Rich Renomeron over 2 years ago

Flickurl, the library behind the flickr integration, appears to support the new OAuth protocol:
http://librdf.org/flickcurl/api/flickcurl-auth.html. It's theoretically possible to "simply" rewrite the authentication code to do it the new way.

#3 Updated by Nick Kachulin over 2 years ago

So, is's not a bug, it's apparently a feature... now I need tokens... will try to handle it these days...
Thanks!

#4 Updated by Rich Renomeron over 2 years ago

After a couple of days of hacking I've been able to get part of the way there, but I seem to be running into this issue with flickcurl:

https://github.com/dajobe/flickcurl/issues/30

While it's been resolved for over two years, there has not been a proper release of flickcurl since then. It's going to take a while, but I will need to build darktable with the latest flickcurl source to make further progress.

You can see my current progress at https://github.com/rrenomeron/darktable/tree/flickcurl-oauth

#5 Updated by Nick Kachulin over 2 years ago

Yeah, apparently it's been known for a couple of years...
As you can see from this ticket https://github.com/dajobe/flickcurl/issues/28
all we need to do is remove one line of code -- given that is is actually an app that is needed just once, the rest of code brush-up can be omitted.
I tried to do this hack but bumped onto my inability to create a patch that could be swallowed by `patch` without the -l option. I seem to count all the spaces several times, copy-pasted the fragment but patch < .... rejects it while patch -l did it just fine... heck..

#6 Updated by Roman Lebedev about 2 years ago

#7 Updated by Roman Lebedev about 2 years ago

  • Has duplicate Bug #11759: flickr authentication broken added

#8 Updated by Stefan Schöfegger almost 2 years ago

@ Rich Renomeron

I had a short look into it.
With info from http://librdf.org/flickcurl/api/flickcurl-auth-authenticate.html i created the ~/.flickcurl.conf file (API is in flickr.c)

[flickr]
  oauth_client_key=XXXXXXXXXXXXX
  oauth_client_secret=XXXX

and then
flickcurl oauth-create

follow instructions.

Attached is a diff that applies on your branch https://github.com/rrenomeron/darktable/tree/flickcurl-oauth for using this ini file for authentication.

Maybe it helps finding a solution

#9 Updated by Nick Kachulin almost 2 years ago

@ Rich Renomeron

Any progress on this?

Meanwhile I gave flickcurl another shot, applied the short "crash free" patch, went thru the auth process and got the tokens.
Still no auth from DT -- when I try to log in flickr redirects to a home page.
Now it's upon darktable I guess. Next move?

#10 Updated by Tobias Ellinghaus almost 2 years ago

Next move would be someone with the time and initiative to sit down and fix the code in dt. We already have exporters that use OAuth, so some boiler plate code can probably be shared, like the local webserver.

#11 Updated by Rich Renomeron almost 2 years ago

Nick Kachulin wrote:

@ Rich Renomeron

Any progress on this?

Not really. I've just checked in on this after many months (I've found that the Flickr web uploader works fine for my purposes). I will try to take a look at your patch in the next week or so.

If I don't make any progress in a few weeks (my C skills have atrophied over many years), I'll likely just commit what I have and see if someone else can pick up the baton.

#12 Updated by Phi Ba over 1 year ago

So any news on this? From a user view it's not very good to have a broken feature in the application. You first need to find out that the problem is not your fault and then go looking for a fix.
If this wont get fixed, it would be better to just remove it from further versions.

#13 Updated by Glenn Dixon 12 months ago

Phi Ba wrote:

So any news on this? From a user view it's not very good to have a broken feature in the application. You first need to find out that the problem is not your fault and then go looking for a fix.
If this wont get fixed, it would be better to just remove it from further versions.

After 17 months I have to agree. Remove the feature from the software until this gets fixed.

#14 Updated by Nick Kachulin 12 months ago

Flickr has changed it's owner and therefore it's rules -- toward a deeper monetization. They've started to rework the design. Most probably the API is the subject to change, too. I doubt I'd stay with Flickr for long: few more changes like what they've changed already and I quit. Hate to say this, but probably the feature has to be removed... If anybody knows the better alternative, just let me (and the others) know. Thanks!

#15 Updated by jean-luc Le Corre 5 months ago

Here is a proposed patch. flickcurl is no longer used, relies on oauth, curl, json and flickr api.

#16 Updated by Jim Robinson 5 months ago

jean-luc Le Corre wrote:

Here is a proposed patch. flickcurl is no longer used, relies on oauth, curl, json and flickr api.

Does this work fully for you? I tried this patch on latest git master (Windows) and logging in to Flickr and exchange of code works. Darktable shows that it has authenticated and the list of albums is populated, but if I then try to export a photo I have to go through the code exchange again and even then the upload often fails with the error

[flickr] Something went wrong when uploading[imageio_storage_flickr] could not upload to flickr!

but sometimes it does upload correctly (maybe a Flickr site issue). Checking the settings on Flickr darktable is not listed as a linked application, which I would have thought it should be after I have autheniticated it. Anyway your efforts are clearly a major step in the right direction. I will soon try to check whether I get the same behaviour with linux (Ubuntu).

#17 Updated by Jim Robinson 5 months ago

Just to confirm that I get the same behaviour with Ubuntu 18.04.

#18 Updated by jean-luc Le Corre 5 months ago

Jim,

Thanks for testing, that made me realise that :

- I forgot to remove a curl timeout used for testing (that prevents upload in case of large file or slow internet)
- I forgot to test with no "password storage backend" set in dt core option settings. (several code exchanges issue) : I think it's your case ?

Here is a patch that should solve that (plus other minor fixes).

Let me know if you still have issues.

#19 Updated by Jim Robinson 5 months ago

Jean-Luc,

Nearly there for me. I can successfully upload batches of images, create new album etc. The one issue I now have is if after having uploaded an image (or a group) I attempt to upload another one. I then get the following error once I click the export button:

failed to get parameters for storage module 'flickr webalbum' aborting export

and darktable then seg faults (both linux and windows).

#20 Updated by jean-luc Le Corre 5 months ago

Jim,

My first attempt to avoid several code exchanges was clearly not smart enough.
This should be fixed now

#21 Updated by Jim Robinson 5 months ago

Jean-Luc,

Looks good to me. All functions as expected under linux, with authentication credentials retained between starts of darktable. On windows 7 an authentication exchange is required on each start of darktable. I think that this is inevitable as (as far as I know) there is no Secret Service implementation for windows. If libsecret is selected as the storage backend errors such as:

[pwstorage_libsecret] error storing password: The name org.freedesktop.secrets is unknown

are reported. Hopefully this will find its way into git master soon.

Also available in: Atom PDF

Go to top