[OAuth2] Authorization fails with a Connection refused after 5min delay

[mirekys]

Expected behaviour

Client's web-side OAuth2 authorization should either succeed or
fail with a meaningful error message to the user (that time period
for authorization has expired an he should try again faster).

Actual behaviour

Connection refused to the following callback URL is shown in the browser after clicking Authorize:

http://localhost:<random_port>/?code=<oauth_code_token>

Steps to reproduce

1. Start the client (will open the ownCloud login page in the browser asking for Client Authorization)
2. Wait for > 5min
3. Now try to authorize the client

Server configuration

Operating system: RHEL7

Web server: Apache

Database: PostgreSQL

PHP version: 7.1

ownCloud version: 10.0.8

Storage backend (external storage): local

OAuth2 provider app enabled on the server

Client configuration

Client version: 2.4.1

Operating system: probably all

OS language: en_US

Qt version used by client package (Linux only, see also Settings dialog): Qt 5.11.0

Client package (From ownCloud or distro) (Linux only): distro

Logs

1. Client logfile:

>>> started the client
06-25 13:55:51:321 [ info sync.connectionvalidator ]:	No system proxy set by OS
06-25 13:55:51:504 [ info sync.networkjob.checkserver ]:	status.php returns:  QJsonDocument({"edition":"Community","installed":true,"maintenance":false,"needsDbUpgrade":false,"productname":"ownCloud","version":"10.0.8.5","versionstring":"10.0.8"})   QNetworkReply::NetworkError(NoError)  Reply:  QNetworkReplyHttpImpl(0x560cfc369ab0)
06-25 13:55:51:505 [ info sync.connectionvalidator ]:	** Application: ownCloud found:  QUrl("https://owncloud")  with version  "10.0.8" ( "10.0.8.5" )
06-25 13:55:51:505 [ info sync.connectionvalidator ]:	QUrl("https://owncloud") has server version "10.0.8.5"
06-25 13:55:51:512 [ info gui.account.state ]:	AccountState connection status change:  "Undefined" -> "Credentials not ready"
06-25 13:55:51:512 [ info gui.account.state ]:	Invalid credentials for "https://owncloud" asking user
06-25 13:55:51:513 [ info gui.account.state ]:	AccountState state change:  "Disconnected" -> "Asking Credentials"
06-25 13:55:51:513 [ info gui.folder.manager ]:	Account "user@owncloud" disconnected or paused, terminating or descheduling sync folders
06-25 13:55:51:614 [ info sync.networkjob.determineauthtype ]:	Determining auth type for QUrl("https://owncloud/remote.php/webdav/")
06-25 13:55:52:844 [ info sync.networkjob.determineauthtype ]:	Auth type for QUrl("https://owncloud/remote.php/webdav/") is 1
06-25 14:00:52:366 [ info gui.account.state ]:	Credentials asked for "https://owncloud" are they ready? false
06-25 14:00:52:367 [ info gui.account.state ]:	AccountState state change:  "Asking Credentials" -> "Signed out"
06-25 14:00:52:369 [ info gui.folder.manager ]:	Account "user@owncloud" disconnected or paused, terminating or descheduling sync folders
<<< no more authorization callbacks after this moment :-(

[SamuAlfageme]

Hey @mirekys! Thanks for reporting! Timing out is actually a good practice not to leave an unused, open connection for too long in any piece of software.

Back in the client's wizard, you have "Re-open in Browser" option once a timeout occurs:

Do you see this after step 2? Re-opening and authorizing works for you?

[ogoffart]

There is a 5 minute timeout i the client. After this timeout we abort the connection procedure. (Forget all the states and stop listening on localhost)

good practice not to leave an unused, open connection for too long in any piece of software.

Not really an open connection, just an open port. (listening on localhost only)

I'm actually considering removing the timeout.
I don't think the open port is a problem. The link to open the browser can still be reached by giving focus back to the client.

There is maximum one active connection attemps per account.

But yes, once connected, or when the wizard is closed, the server is shut down. So the browser will not be able to connect.
Maybe it would be even more user friendly have only one connection, so the client can display a nicer error.
But that's not so easy as we would then have to find another way to dispatch between the account. (I'm not sure if we can change the redirect_uri to contain more parameters or if this is hardcoded in the server)

Overall I think this is a minor inconvinience, and probably not worth fixing.
Yet i'm still wondering if the timeout is a good or bad thing.

[mirekys]

Hello @SamuAlfageme , I'm using an already configured account in the client (which was previously set up using BaseAuth), not the wizard, and in that case only a message 'Signed out from server x as user y' is shown in the client.

I share the same viewpoint that this is just a minor inconvinience for the user, and I'm okay with the timeout. But we already received some complaints about this, because it looks scary for the users. :) Maybe the server listening on the port for callback can be replaced by something simple that just serves a nice static error page after the timeout occurs?
Thank you for considering this.

[guruz]

Yet i'm still wondering if the timeout is a good or bad thing.

Yes, please remove the timeout. I'd agree with @mirekys .. it looks scary to users.
(Also backport 2.4.2?)

[ogoffart]

Timeout removed: #6617

[jnweiger]

No more timeout seen. (or longer than 10min :-)

The browser will show error messages, if the client goes away e.g. like this:
Press back on the wizard to view the url entry page again, then press 'authenticate'

That probably cannot be helped. (Except by some javascript magic, polling the localhost port, and then graying out the authorize button, until a client comes back.)