Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Autostart on the client breaks transparent OAuth's token refresh #6522

Closed
SamuAlfageme opened this issue May 14, 2018 · 9 comments
Closed

Autostart on the client breaks transparent OAuth's token refresh #6522

SamuAlfageme opened this issue May 14, 2018 · 9 comments
Assignees
@ogoffart @SamuAlfageme
Labels
blue-ticket ReadyToTest QA, please validate the fix/enhancement type:bug
Milestone
2.4.2

Comments

@SamuAlfageme
Copy link
Contributor

SamuAlfageme commented May 14, 2018 •
edited
Loading

Last Friday I was debugging an apparent OAuth2 issue with @Helios07 that turned out to be a problem with the auto-start feature of the client.

When auto-start is enabled, the client seems to be starting before the keychain/keyring service on the OS and therefore, without access to the stored refresh token. This causes the client to start the authorize workflow from scratch.

We detected this behavior on a couple of Linux distros (Ubuntu and Fedora) - but it might not limit to Linux only.

Actual behavior

Client pops up the "Authorize Desktop client..." browser window.

Expected behavior

Delay the client login up until the password-store service is (back) online. See also #6440

Steps to reproduce

  1. Enable auto-start on the client
  2. Log-in via OAuth2 to an account
  3. Restart the OS
@SamuAlfageme SamuAlfageme added this to the 2.4.2-maybe milestone May 14, 2018
@ogoffart
Copy link
Contributor

I guess that's a duplicate of this one:
#4274

Not much we can do about it.... maybe add some seconds of timer on first attempt and do another attempt...

ogoffart added a commit that referenced this issue May 14, 2018
@ogoffart
Credentials: Retry fetching from the keychain in case the keychain is…
da01944 
… still starting

When owncloud is restored, at boot time, it might be started before the
crendential manager. So if we detect an error, wait 10 seconds and hopefully
it'd be loaded by then.

Issues: #4274, #6522
@ogoffart ogoffart mentioned this issue May 14, 2018
Merged
@guruz
Copy link
Contributor

guruz commented May 15, 2018

(We have X-GNOME-Autostart-Delay=3 in the .desktop file but it's not supported everywhere. )

@ogoffart
Copy link
Contributor

Plasma don't understand X-GNOME-Autostart-Delay, But maybe we could try to use X-KDE-autostart-phase=2 or X-KDE-autostart-after=????

@guruz
Copy link
Contributor

guruz commented May 16, 2018

Additionally yes. Viel hilft Viel ;-)

guruz pushed a commit that referenced this issue May 24, 2018
@ogoffart @guruz
Credentials: Retry fetching from the keychain in case the keychain is…
c625d8e 
… still starting

When owncloud is restored, at boot time, it might be started before the
crendential manager. So if we detect an error, wait 10 seconds and hopefully
it'd be loaded by then.

Issues: #4274, #6522
@guruz guruz added the ReadyToTest QA, please validate the fix/enhancement label May 24, 2018
guruz pushed a commit that referenced this issue May 24, 2018
@ogoffart @guruz
Credentials: Retry fetching from the keychain in case the keychain is…
084f522 
… still starting

When owncloud is restored, at boot time, it might be started before the
crendential manager. So if we detect an error, wait 10 seconds and hopefully
it'd be loaded by then.

Issues: #4274, #6522
(cherry picked from commit c625d8e)
@camilasan camilasan mentioned this issue Jun 3, 2018
Merged
@cleverer
Copy link

Not sure if this is the same issue or another one:
If I have no internet connection on my Mac and owncloud launches, everything is fine. But as soon as the internet comes back up, I have to reauthorize my OAuth2 accounts.
If I then quit the client and reopen it, it connects successfully again.

OS: macOS 10.13.5, Client: owncloud 2.4.1 (build 9367), Server: 10.0.8.5

@SamuAlfageme
Copy link
Contributor Author

@cleverer thanks for reporting! Yeah, it might be a different form of the same issue.

Just to be clear, you don't re-authorize the client in the browser right? Just reopening the client makes it work? That might point at #6357 as real cause: the first unauthorized call races against the function that fetches the credentials from the keychain service.

@ogoffart might be worth taking a look at this. Will try to reproduce

@cleverer
Copy link

@SamuAlfageme Yes, I'm just closing the browser windows. Of course sync also continues normally when re-authorizing.
Its especially annoying, if you have a corporate WiFi which only connects when you are logged in to your User account. Often owncloud is already started by the point the WiFi connects.

I'm happy to open a new issue or contribute in any way I can, but I'm a bit unfamiliar with ownclouds workflows…

ogoffart added a commit that referenced this issue Jun 13, 2018
@ogoffart
OAuth2: Try to refresh the token even if the credentials weren't ready.
5ca0548 
This can happen when the client is started and the internet connection
was not enabled. Then we would fetch the credentials, but we would
no do the refresh token step (because network is down).
So next time we try to connect, we would also not refresh the token
because the credentials are not marked as 'ready'

Reported in
#6522 (comment)
@ogoffart ogoffart mentioned this issue Jun 13, 2018
Merged
@ogoffart
Copy link
Contributor

@cleverer thanks for reporting.

Will be fixed with #6583

ogoffart added a commit that referenced this issue Jun 14, 2018
@ogoffart
OAuth2: Try to refresh the token even if the credentials weren't ready.
4cc0539 
This can happen when the client is started and the internet connection
was not enabled. Then we would fetch the credentials, but we would
no do the refresh token step (because network is down).
So next time we try to connect, we would also not refresh the token
because the credentials are not marked as 'ready'

Reported in
#6522 (comment)
guruz pushed a commit that referenced this issue Jun 20, 2018
@ogoffart @guruz
OAuth2: Try to refresh the token even if the credentials weren't ready.
7efc322 
This can happen when the client is started and the internet connection
was not enabled. Then we would fetch the credentials, but we would
no do the refresh token step (because network is down).
So next time we try to connect, we would also not refresh the token
because the credentials are not marked as 'ready'

Reported in
#6522 (comment)

(cherry picked from commit 4cc0539)
@guruz
Copy link
Contributor

guruz commented Jul 18, 2018

If there are still issues with 2.4.2 coming out really soon now™ please open a new issue here.

@guruz guruz closed this as completed Jul 18, 2018
camilasan pushed a commit to nextcloud/desktop that referenced this issue Sep 9, 2018
@ogoffart
OAuth2: Try to refresh the token even if the credentials weren't ready.
a68c955 
This can happen when the client is started and the internet connection
was not enabled. Then we would fetch the credentials, but we would
no do the refresh token step (because network is down).
So next time we try to connect, we would also not refresh the token
because the credentials are not marked as 'ready'

Reported in
owncloud/client#6522 (comment)
@camilasan camilasan mentioned this issue Sep 9, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ogoffart ogoffart

@SamuAlfageme SamuAlfageme

Labels
blue-ticket ReadyToTest QA, please validate the fix/enhancement type:bug
Projects
None yet
Milestone
2.4.2
Development

No branches or pull requests
4 participants
@ogoffart @guruz @cleverer @SamuAlfageme