[digiKam-users] Export to Flickr
Locked
 
|
I am a new digiKam user and am trying to setup a workflow for exporting to Flickr. I am having a problem with the authentication process. I am using digiKam 6.4.0 on Mac OS Majave (10.14.6). The Oauth process is initiated, but the oauth server on the my side
does not seem to exist at: https://127.0.0.1:1965/?oauth_token=[token]&oauth_verifier=[verifier]. I have tried it with Chrome
as my default browser as well as Safari. Chrome says that I am getting an SSL error and Safari just says it cannot connect.
I was able to successfully setup the authentication for Google Photos which also uses an Oauth authentication flow, but I noticed that it is using port 8000.
Any hint on why the authentication server on my end is not working for Flickr?
Thanks in advance.
Tom
|
|
|
The problem was solved in digiKam-7.0.0-beta1. Flickr has switched to https at
the callback address. A connection to the computer is therefore no longer possible. We are now using an internal browser. The digiKam-7.0.0-Beta1 for MacOS is available here: https://files.kde.org/digikam/ Maik Am Donnerstag, 26. Dezember 2019, 22:56:45 CET schrieb Tom Talbott: > I am a new digiKam user and am trying to setup a workflow for exporting to > Flickr. I am having a problem with the authentication process. I am using > digiKam 6.4.0 on Mac OS Majave (10.14.6). The Oauth process is initiated, > but the oauth server on the my side does not seem to exist at: > https://127.0.0.1:1965/?oauth_token=[token]&oauth_verifier=[<https://127.0. > 0.1:1965/?oauth_token=72157712374763241-ddabcf4fb0045451&oauth_verifier=da4f > b0086a4bece>verifier]. I have tried it with Chrome as my default browser as > well as Safari. Chrome says that I am getting an SSL error and Safari just > says it cannot connect. > > I was able to successfully setup the authentication for Google Photos which > also uses an Oauth authentication flow, but I noticed that it is using port > 8000. > > Any hint on why the authentication server on my end is not working for > Flickr? > > Thanks in advance. > > Tom |
|
|
Thanks for the reply! I'll wait for a stable version and try again.
From: Digikam-users <[hidden email]> on behalf of Maik Qualmann <[hidden email]>
Sent: Thursday, December 26, 2019 2:08 PM To: digiKam - Home Manage your photographs as a professional with the power of open source <[hidden email]> Subject: Re: [digiKam-users] Export to Flickr The problem was solved in digiKam-7.0.0-beta1. Flickr has switched to https at
the callback address. A connection to the computer is therefore no longer possible. We are now using an internal browser. The digiKam-7.0.0-Beta1 for MacOS is available here: https://files.kde.org/digikam/ Maik Am Donnerstag, 26. Dezember 2019, 22:56:45 CET schrieb Tom Talbott: > I am a new digiKam user and am trying to setup a workflow for exporting to > Flickr. I am having a problem with the authentication process. I am using > digiKam 6.4.0 on Mac OS Majave (10.14.6). The Oauth process is initiated, > but the oauth server on the my side does not seem to exist at: > https://127.0.0.1:1965/?oauth_token=[token]&oauth_verifier=[<https://127.0. > 0.1:1965/?oauth_token=72157712374763241-ddabcf4fb0045451&oauth_verifier=da4f > b0086a4bece>verifier]. I have tried it with Chrome as my default browser as > well as Safari. Chrome says that I am getting an SSL error and Safari just > says it cannot connect. > > I was able to successfully setup the authentication for Google Photos which > also uses an Oauth authentication flow, but I noticed that it is using port > 8000. > > Any hint on why the authentication server on my end is not working for > Flickr? > > Thanks in advance. > > Tom |
|
In reply to this post by Maik Qualmann
Maik Qualmann wrote
> The problem was solved in digiKam-7.0.0-beta1. Flickr has switched to > https at > the callback address. Cool, but sorry to say, it doesn't work for me, using digiKam-7.0.0-beta2 After writing my flickr user and pass, it doesn't venture passed the login screen. It just stays there. If I write the wrong password it _does_ complain, so I assume it's the forward from a successful login that fails. It seems as if the flickr login dialogue JS doesn't work on the built-in browser :-( And hints on how I may work around this problem? Cheers, -Torstein dK: digikam-7.0.0-beta2-20200108T085258-x86-64.appimage OS: Debian/Linux, i3, X.org 7.7 -- Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
|
|
Ok, here with my native developer version that uses the QWebEngine, it works
without problems. For various reasons, the Windows version and AppImage use the older QWebkit engine. Let's see if I can fix it or find a workaround. Because it almost looks to me as if the login to Flickr doesn't work with QWebkit. Maik Am Mittwoch, 8. Januar 2020, 22:59:48 CET schrieb skybert: > Maik Qualmann wrote > > > The problem was solved in digiKam-7.0.0-beta1. Flickr has switched to > > https at > > the callback address. > > Cool, but sorry to say, it doesn't work for me, using digiKam-7.0.0-beta2 > > After writing my flickr user and pass, it doesn't venture passed the login > screen. It just stays there. If I write the wrong password it _does_ > complain, so I assume it's the forward from a successful login that fails. > It seems as if the flickr login dialogue JS doesn't work on the built-in > browser :-( > > And hints on how I may work around this problem? > > Cheers, > > -Torstein > > dK: digikam-7.0.0-beta2-20200108T085258-x86-64.appimage > OS: Debian/Linux, i3, X.org 7.7 > > > > -- > Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
|
|
Maik, While updating all bundles to Qt5.14 (Windows and AppImage done, MacOs under way), i discovered that current implementation of QtWebkit use a similar way than QtWebEngine to handle web requests from the browser through a 3rd party process. And actually, these process, located in QT5_INSTALL_DIR/libexec are not yet included in the bundles. I will fix this point today. Gilles Le jeu. 9 janv. 2020 à 23:10, Maik Qualmann <[hidden email]> a écrit : Ok, here with my native developer version that uses the QWebEngine, it works |
|
|
Tom, The weekly pre-release bundles are updated. Please test again... Gilles Caulier Le ven. 10 janv. 2020 à 01:52, Gilles Caulier <[hidden email]> a écrit :
|
|
|
The problem is still there. I compiled my native Linux version with QWebkit
and can confirm the problem here too. It is independent of the Flickr tool and also exists in our help browser, a normal login to Flickr is not possible. Login is possible in Konqueror, since both Konqueror and our browser show the same graphic error (icon in front of the email address has been moved), I suspect that a certain QWebSettings setting may be missing. Maik Am Freitag, 10. Januar 2020, 19:31:20 CET schrieb Gilles Caulier: > Tom, > > The weekly pre-release bundles are updated. Please test again... > > https://files.kde.org/digikam/ > > Gilles Caulier > > Le ven. 10 janv. 2020 à 01:52, Gilles Caulier <[hidden email]> a > > écrit : > > Maik, > > > > While updating all bundles to Qt5.14 (Windows and AppImage done, MacOs > > under way), i discovered that current implementation of QtWebkit use a > > similar way than QtWebEngine to handle web requests from the browser > > through a 3rd party process. And actually, these process, located in > > QT5_INSTALL_DIR/libexec are not yet included in the bundles. > > > > I will fix this point today. > > > > Gilles > > > > Le jeu. 9 janv. 2020 à 23:10, Maik Qualmann <[hidden email]> a > > > > écrit : > >> Ok, here with my native developer version that uses the QWebEngine, it > >> works > >> without problems. For various reasons, the Windows version and AppImage > >> use > >> the older QWebkit engine. Let's see if I can fix it or find a workaround. > >> Because it almost looks to me as if the login to Flickr doesn't work with > >> QWebkit. > >> > >> Maik > >> > >> Am Mittwoch, 8. Januar 2020, 22:59:48 CET schrieb skybert: > >> > Maik Qualmann wrote > >> > > >> > > The problem was solved in digiKam-7.0.0-beta1. Flickr has switched to > >> > > https at > >> > > the callback address. > >> > > >> > Cool, but sorry to say, it doesn't work for me, using > >> > >> digiKam-7.0.0-beta2 > >> > >> > After writing my flickr user and pass, it doesn't venture passed the > >> > >> login > >> > >> > screen. It just stays there. If I write the wrong password it _does_ > >> > complain, so I assume it's the forward from a successful login that > >> > >> fails. > >> > >> > It seems as if the flickr login dialogue JS doesn't work on the > >> > built-in > >> > browser :-( > >> > > >> > And hints on how I may work around this problem? > >> > > >> > Cheers, > >> > > >> > -Torstein > >> > > >> > dK: digikam-7.0.0-beta2-20200108T085258-x86-64.appimage > >> > OS: Debian/Linux, i3, X.org 7.7 > >> > > >> > > >> > > >> > -- > >> > >> > Sent from: > >> http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
|
|
Note : the original problem come from MacOS, where QtWebkit is the older one 5.9.1 from Macports package. It do not use 5.11.3 tarball released in november 2019, as under MXE. I recompiled here the right version of QtWebkit 5.13 with Macports, but there are linking problem while bundeling. I will add the QtWebEngine supports in MacOS, through an option as with AppImage, to see if this work without problem. At least Macports wth Qt 5.14.0 supports de facto QtWebEngine. Gilles Le sam. 11 janv. 2020 à 00:29, Maik Qualmann <[hidden email]> a écrit : The problem is still there. I compiled my native Linux version with QWebkit |
|
|
Fixed with this commit:
https://invent.kde.org/kde/digikam/commit/abd2ab8d36e7e21a398ca312a706454682f38d8a
Am Samstag, 11. Januar 2020, 04:45:50 CET schrieb Gilles Caulier: > Note : the original problem come from MacOS, where QtWebkit is the older > one 5.9.1 from Macports package. It do not use 5.11.3 tarball released in > november 2019, as under MXE. > > I recompiled here the right version of QtWebkit 5.13 with Macports, but > there are linking problem while bundeling. > > I will add the QtWebEngine supports in MacOS, through an option as with > AppImage, to see if this work without problem. At least Macports wth Qt > 5.14.0 supports de facto QtWebEngine. > > Gilles > > Le sam. 11 janv. 2020 à 00:29, Maik Qualmann <[hidden email]> a > > écrit : > > The problem is still there. I compiled my native Linux version with > > QWebkit > > and can confirm the problem here too. It is independent of the Flickr tool > > and > > also exists in our help browser, a normal login to Flickr is not possible. > > Login is possible in Konqueror, since both Konqueror and our browser show > > the > > same graphic error (icon in front of the email address has been moved), I > > suspect that a certain QWebSettings setting may be missing. > > > > Maik > > > > Am Freitag, 10. Januar 2020, 19:31:20 CET schrieb Gilles Caulier: > > > Tom, > > > > > > The weekly pre-release bundles are updated. Please test again... > > > > > > https://files.kde.org/digikam/ > > > > > > Gilles Caulier > > > > > > Le ven. 10 janv. 2020 à 01:52, Gilles Caulier <[hidden email]> > > > > a > > > > > écrit : > > > > Maik, > > > > > > > > While updating all bundles to Qt5.14 (Windows and AppImage done, MacOs > > > > under way), i discovered that current implementation of QtWebkit use a > > > > similar way than QtWebEngine to handle web requests from the browser > > > > through a 3rd party process. And actually, these process, located in > > > > QT5_INSTALL_DIR/libexec are not yet included in the bundles. > > > > > > > > I will fix this point today. > > > > > > > > Gilles > > > > > > > > Le jeu. 9 janv. 2020 à 23:10, Maik Qualmann <[hidden email]> a > > > > > > > > écrit : > > > >> Ok, here with my native developer version that uses the QWebEngine, > > > >> it > > > >> works > > > >> without problems. For various reasons, the Windows version and > > > > AppImage > > > > > >> use > > > >> the older QWebkit engine. Let's see if I can fix it or find a > > > > workaround. > > > > > >> Because it almost looks to me as if the login to Flickr doesn't work > > > > with > > > > > >> QWebkit. > > > >> > > > >> Maik > > > >> > > > >> Am Mittwoch, 8. Januar 2020, 22:59:48 CET schrieb skybert: > > > >> > Maik Qualmann wrote > > > >> > > > > >> > > The problem was solved in digiKam-7.0.0-beta1. Flickr has > > > > switched to > > > > > >> > > https at > > > >> > > the callback address. > > > >> > > > > >> > Cool, but sorry to say, it doesn't work for me, using > > > >> > > > >> digiKam-7.0.0-beta2 > > > >> > > > >> > After writing my flickr user and pass, it doesn't venture passed > > > >> > the > > > >> > > > >> login > > > >> > > > >> > screen. It just stays there. If I write the wrong password it > > > >> > _does_ > > > >> > complain, so I assume it's the forward from a successful login that > > > >> > > > >> fails. > > > >> > > > >> > It seems as if the flickr login dialogue JS doesn't work on the > > > >> > built-in > > > >> > browser :-( > > > >> > > > > >> > And hints on how I may work around this problem? > > > >> > > > > >> > Cheers, > > > >> > > > > >> > -Torstein > > > >> > > > > >> > dK: digikam-7.0.0-beta2-20200108T085258-x86-64.appimage > > > >> > OS: Debian/Linux, i3, X.org 7.7 > > > >> > > > > >> > > > > >> > > > > >> > -- > > > >> > > > >> > Sent from: > > > >> http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html
|
|
|
Tom, I currently recompile whole MacOS package. It run since 3 hours and it completed to 66%. This version, if it work, will be based on Qt5.14 + QtWebEngine, not QtWebKit (I'm facing problems with this last one). So please wait. Gilles Caulier Le sam. 11 janv. 2020 à 15:42, Maik Qualmann <[hidden email]> a écrit :
|
|
|
Ok, MacOS PKG build properly now with Qt 5.14 + QtWebEngine. Maik, QtWebEngine do not crash under Linux at end of DK session. Great. Perhaps we can make a try with this combinaison into AppImage bundle. Tom, I rebuild the PKG now with last changes from Maik, and i will publish the file on weekly build repository for testing, as usual... Gilles Le sam. 11 janv. 2020 à 18:29, Gilles Caulier <[hidden email]> a écrit :
|
|
|
Tom, new DK MacOS PKG 7.0.0-beta2 is ready to test here : Gilles Caulier Le dim. 12 janv. 2020 à 02:58, Gilles Caulier <[hidden email]> a écrit :
|
| Free forum by Nabble | Edit this page |