Saved authorisation is not working after system reboot


#1

Expected behaviour

OAuth2 authorisation is saved in kdewallet, used again after reboot.

Actual behaviour

While kdewallet shows the entry saved by ownCloud, it seems not to be used by the ownCloud client. Instead, the OAuth2 authorisation page is loaded in a web browser at every startup.

Steps to reproduce

  1. New install of ownCloud with kdewallet configured.
  2. Add new account in ownCloud with OAuth2 authorisation.
  3. Restart system.
  4. Saved OAuth2 authorisation is not used, new confirmation required in automatically opened web browser.

Server configuration

Web server:
https://uni-muenster.sciebo.de

Client configuration

Client version:
2.4.1+dfsg-1
Operating system:
Kubuntu 18.04
OS language:
German
Qt version used by client package (Linux only, see also Settings dialog):

Client package (From ownCloud or distro) (Linux only):
from ownCloud package repository
Installation path of client:
default


#2

Hey,

it seems the sciebo.de ownCloud is using 10.0.4 (https://uni-muenster.sciebo.de/status.php) where 10.0.8 is current (https://owncloud.org/changelog/server/).

The releases after 10.0.4 mentioned quite some fixes for OAuth so i think it might be related to this outdated version.


#3

Hey,
thanks for looking up! Is there any way on my side to confirm this, and even deeper: is there a workaround like disabling OAuth for some time?


#4

I’m not sure if there is that much you can do if this not your own server :confused:. Maybe you can setup an own ownCloud 10.0.8 installation and try your current version of the client against that that installation?

As an alternative you could also try the official client from https://owncloud.org/download/#owncloud-desktop-client-linux . From what i have read in the past this differs in various points from the one shipped in Linux-Distros like Ubuntu/Debian and so on.


#5

Hm, indeed i’m using already the official client, the precompiled one from the owncloud repository, for Ubuntu 18.04 – therefore i was so curious whether its possible to find out what is happening in the moments, when the authorisation is required again, to exclude that it would be on the client side. Searching to access a log, adding here if found :wink:


#6

Logging: done by ending the client, and executing newly with “owncloud --logwindow”.

That log revealed: authorisation always working smoothly. Aha, whats the difference? Just when starting directly from KDE autostart, the (wired) network connection is just establishing. That short moment of network-not-yet-availability :wink: is enough to let the owncloud client trigger opening a browser window, asking for the OAuth confirmation. I didnt notice that detail before, since even when the browser is there, also the network connection is already fully there. Well, at least this seems to be the consistent interpretation to me. So i would call it sub-optimal, that the owncloud client seems not fully dealing with an upstarting system / upstarting network connection (?). Quick system freshly installed using SSD directly on PCIe x4 now.

"Solved" here by: changing the autostart command from “/usr/bin/owncloud” to “sleep 14; /usr/bin/owncloud”.

… and, to avoid the client from being restored in the KDE Plasma session already before autostart (since it was always running on the end fo the last KDE session), excluded owncloud explicitly from that restoration. Entry in KDE “System settings” -> “Startup and Shutdown” -> “Desktop session” -> “Applications to be excluded from sessions”.

Thanks for all replies!


#7

Hey @philippk thanks for your report! We in the client team are pretty much aware of this limitation. Couple of weeks ago I opened this report:

We actually introduced the autostart delay that solved your issue into our upcoming 2.5 release. However it seems not to be enough since the delay should be pretty much dependent in the system load (i.e. the time KWallet/Gnome Keyring… takes to start completely). We’ll be rethinking this solution from the ground up, keep you posted on the GitHub issue.

Thanks again for your report.


#8

Just a side-note to this:

If the initial Client version 2.4.1+dfsg-1 is correct then the one of Ubuntu is used and not the official one of ownCloud which currently has version 2.4.1-9083. I think there are some differences in e.g. some additional QT5 patches and similar. Maybe @alfageme could confirm this?


#9

Indeed, there are a few differences between the dfsg-1 (ubuntu’s version; pulled from their repos) and 2.4.1 standalone. Basically in terms of build dependencies and libraries. e.g. one of the most outstanding problems with their version was:

We always recommend users to install ownCloud self built packages since we control and QA those.