Bug 411521 - [digikam/WebService/O2] local socket port should be configurable
Summary: [digikam/WebService/O2] local socket port should be configurable
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-WebService-Google (show other bugs)
Version: 6.2.0
Platform: Compiled Sources All
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-02 10:50 UTC by RJVB
Modified: 2022-06-20 17:10 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description RJVB 2019-09-02 10:50:15 UTC
SUMMARY
digiKam currently hardwires the local port for the O2 WebService layer, for most plugins port 8000. This prevents the services from working when that port is already in use, for instance for the proxy. It is all the more problematic since 8000 is a quite common port.

STEPS TO REPRODUCE
1. start digiKam with a local service that already uses port 8000
2. try to import Google Photos

OBSERVED RESULT
O2::link: Reply server failed to start listening on port 8000


EXPECTED RESULT
A functioning import from Google Photos


ADDITIONAL INFORMATION
I'm reporting this for the Google plugin but I see that most other plugins also use port 8000. A less common port would be a better choice (e.g. 27648, the low 2 bytes of the fourcc 'dkam'). But ideally there should be a configure option (or at least an override via an env.var.) for this port number, at least for those services which don't impose a specific port. Google Photos doesn't seem to care.
Comment 1 Maik Qualmann 2019-09-02 11:30:37 UTC
A configuration by the user is not possible. We have to deposit the callback address including port number on Google. It is only changeable in our app account to the service. Most services check whether the sent callback address is identical to the deposited in the app account. We can agree on a different address, but that would mean that all previous digiKam version would not work anymore. The future will be that we use a built-in browser for login, so we can get the login token. But on many systems there are still problems with QWebEngine. And QWebKit seems to be evolving, but I would not like to use it for login right now.

Maik
Comment 2 caulier.gilles 2019-09-02 11:37:28 UTC
Note : remember that Qt5 include now a framework component dedicated to replace the O2 library included in DK core:

https://doc.qt.io/qt-5/qtnetworkauth-index.html

Gilles Caulier
Comment 3 Maik Qualmann 2019-09-02 11:45:57 UTC
A proxy normally runs on 8080. The port 8000 should actually be free for most users.
Also Qt5 needs a callback address with port number, which we would have to specify.

Maik
Comment 4 RJVB 2019-09-02 13:02:59 UTC
I replaced the setLocalPort call to use port 8888 before I filed this issue (and after I discovered I could no longer connect). I had to go through the login procedure (handed off to the web browser), but access still works fine after restarting digiKam.
Comment 5 Maik Qualmann 2019-09-02 20:46:48 UTC
The port is needed only once at the first login. Later, the stored access token from the "digikam_oauthrc" is used. This is valid for some time depending on the service.

Maik
Comment 6 caulier.gilles 2020-08-04 05:13:18 UTC
Maik, 

I propose to close this file as intentional. Nothing can be changed due to Google requirement.

Gilles
Comment 7 Maik Qualmann 2020-08-04 05:49:23 UTC
We can and must use the internal browser in the future to receive the token. I have already prepared the code, a complete changeover is not very complex. But for a clean solution, I would have to change the return address in the Google account. At this point, all older digiKam versions could not login again. At the latest when Google no longer allows unencrypted return addresses like Flickr, we have to do it.

Otherwise yes, a user cannot change the specified port address, we should close the bug.

Maik
Comment 8 RJVB 2020-08-04 10:40:42 UTC
(In reply to Maik Qualmann from comment #1)
> And QWebKit seems to be evolving, but I
> would not like to use it for login right now.

It is, and it is much more suitable as an embedded web engine.
Login works fine. I wouldn't log in to my bank or utilities accounts with it, but the version used in 5.212.alpha4 isn't so old that I'd fear logging into my google account with it.
Comment 9 Maik Qualmann 2022-06-20 17:10:59 UTC
Git commit 979c3f318fea3d4b14d525c2d45d10f801beccd9 by Maik Qualmann.
Committed on 20/06/2022 at 17:09.
Pushed by mqualmann into branch 'master'.

port Google Export Tool to QOAuth2AuthorizationCodeFlow
Related: bug 440156, bug 435384, bug 415365, bug 396671, bug 419956
FIXED-IN: 8.0.0

M  +3    -1    NEWS
M  +2    -1    core/cmake/macros/MacroDPlugins.cmake
M  +1    -0    core/cmake/rules/RulesQtFramework.cmake
M  +2    -1    core/dplugins/generic/webservices/google/CMakeLists.txt
M  +11   -31   core/dplugins/generic/webservices/google/gdrive/gdtalker.cpp
M  +35   -63   core/dplugins/generic/webservices/google/gphoto/gptalker.cpp
M  +77   -83   core/dplugins/generic/webservices/google/gstalkerbase.cpp
M  +8    -9    core/dplugins/generic/webservices/google/gstalkerbase.h
M  +44   -1    core/libs/dplugins/webservices/wstoolutils.cpp
M  +10   -0    core/libs/dplugins/webservices/wstoolutils.h

https://invent.kde.org/graphics/digikam/commit/979c3f318fea3d4b14d525c2d45d10f801beccd9