Unable to start owncloud client: First setup wizard redirects to cern sso page

[giorgosalex]

Owncloud nightly client, setup wizard redirects me to the cern sso page for the log in, something it shouldnt happen. So im unable to start the client. Problem with redirects sill there as @moscicki noted in #6086 issue.

[ckamm]

@giorgosalex Could you give me log output, the full one that you get with --logdebug? After the recent adjustments there should be no difference in non-fallback behavior left. If it's too big feel free to email me at mail at ckamm de.

[michaelstingl]

@SamuAlfageme related to #6135 ?

[SamuAlfageme]

Collateral of the behavior introduced for #5954 and #6106

The thing is, using the webUI you get redirected to the IDP, but the client still used basic auth in pre-2.4, don't really know how to sort these kind of hybrid setups:

2.3.3

11-08 11:36:35:269 [ info sync.accessmanager ]:	2 "" "http://<server>/status.php" has X-Request-ID "95c286c4-496f-4d5c-b101-bea1576e024e"
11-08 11:36:35:270 [ info sync.networkjob ]:	OCC::CheckServerJob created for "http://<server>/" + "status.php" "OCC::OwncloudSetupWizard"
11-08 11:36:36:651 [ info sync.networkjob.checkserver ]:	status.php was permanently redirected to QUrl("https://<server>/status.php") new server url is QUrl("https://<server>")
11-08 11:36:36:652 [ info sync.networkjob ]:	Redirecting "GET" QUrl("http://<server>/status.php") QUrl("https://<server>/status.php")
11-08 11:36:36:652 [ info sync.accessmanager ]:	2 "" "https://<server>/status.php" has X-Request-ID "3b04d4da-6d5e-4ee2-b340-0cba4e4c463f"
11-08 11:36:37:061 [ info sync.networkjob.checkserver ]:	status.php returns:  QJsonDocument({"edition":"cernbox","installed":"true","version":"8.0.2","versionstring":"8.0.2"})   QNetworkReply::NetworkError(NoError)  Reply:  QNetworkReplyHttpImpl(0x7fd943d261a0)
11-08 11:36:37:062 [ info gui.wizard ]:	 was redirected to "https://<server>"
11-08 11:36:37:062 [ info sync.networkjob.determineauthtype ]:	Determining auth type for QUrl("https://<server>/remote.php/webdav/")
11-08 11:36:37:062 [ info sync.accessmanager ]:	2 "" "https://<server>/remote.php/webdav/" has X-Request-ID "baf4c24b-53be-419d-bca7-17e3124b677a"
11-08 11:36:37:063 [ info sync.networkjob ]:	OCC::SimpleNetworkJob created for "https://<server>" + "" "OCC::Account"
11-08 11:36:37:063 [ info sync.accessmanager ]:	6 "PROPFIND" "https://<server>/remote.php/webdav/" has X-Request-ID "50ebe178-ed2b-496d-bf4a-6b8a3cbad23b"
11-08 11:36:37:064 [ info sync.networkjob ]:	OCC::SimpleNetworkJob created for "https://<server>" + "" "OCC::Account"
11-08 11:36:37:201 [ info sync.networkjob ]:	Redirecting "GET" QUrl("https://<server>/remote.php/webdav/") QUrl("https://<idp>/adfs/ls/?wa=wsignin1.0&wreply=https%3A%2F%2Fowncloud_prod_backend%2FShibboleth.sso%2FADFS&wct=2017-11-08T10%3A36%3A36Z&wtrealm=https%3A%2F%2F<server>%2FShibboleth.sso%2FADFS&wctx=cookie%3A1510137396_2895")
11-08 11:36:37:202 [ info sync.accessmanager ]:	2 "" "https://<idp>/adfs/ls/?wa=wsignin1.0&wreply=https%3A%2F%2Fowncloud_prod_backend%2FShibboleth.sso%2FADFS&wct=2017-11-08T10%3A36%3A36Z&wtrealm=https%3A%2F%2F<server>%2FShibboleth.sso%2FADFS&wctx=cookie%3A1510137396_2895" has X-Request-ID "43a63b52-2e06-4414-8d4a-8b3f7974578a"
11-08 11:36:37:342 [ info sync.networkjob ]:	Redirecting "PROPFIND" QUrl("https://<server>/remote.php/webdav/") QUrl("https://<idp>/adfs/ls/?wa=wsignin1.0&wreply=https%3A%2F%2Fowncloud_prod_backend%2FShibboleth.sso%2FADFS&wct=2017-11-08T10%3A36%3A37Z&wtrealm=https%3A%2F%2F<server>%2FShibboleth.sso%2FADFS&wctx=cookie%3A1510137397_c2a9")
11-08 11:36:37:343 [ info sync.accessmanager ]:	6 "PROPFIND" "https://<idp>/adfs/ls/?wa=wsignin1.0&wreply=https%3A%2F%2Fowncloud_prod_backend%2FShibboleth.sso%2FADFS&wct=2017-11-08T10%3A36%3A37Z&wtrealm=https%3A%2F%2F<server>%2FShibboleth.sso%2FADFS&wctx=cookie%3A1510137397_c2a9" has X-Request-ID "6543336a-3f6d-4673-b617-62c93522b23b"
11-08 11:36:38:255 [ info sync.networkjob.determineauthtype ]:	Auth type for QUrl("https://<server>/remote.php/webdav/") is 1

2.4.0 nightly

11-08 11:44:38:982 [ info sync.accessmanager ]:	2 "" "http://<server>/status.php" has X-Request-ID "1c18c4d3-459f-4dbc-b06b-ce7cfdc0e8db"
11-08 11:44:38:982 [ info sync.networkjob ]:	OCC::CheckServerJob created for "http://<server>/" + "status.php" "OCC::OwncloudSetupWizard"
11-08 11:44:39:201 [ info sync.networkjob.checkserver ]:	status.php was permanently redirected to QUrl("https://<server>/status.php") new server url is QUrl("https://<server>")
11-08 11:44:39:201 [ info sync.networkjob ]:	Redirecting "GET" QUrl("http://<server>/status.php") QUrl("https://<server>/status.php")
11-08 11:44:39:202 [ info sync.accessmanager ]:	2 "" "https://<server>/status.php" has X-Request-ID "58548f1a-d2e6-4849-a20c-d3628d7ce30d"
11-08 11:44:39:672 [ info sync.networkjob.checkserver ]:	status.php returns:  QJsonDocument({"edition":"cernbox","installed":"true","version":"8.0.2","versionstring":"8.0.2"})   QNetworkReply::NetworkError(NoError)  Reply:  QNetworkReplyHttpImpl(0x7fb4ee22dcb0)
11-08 11:44:39:673 [ info gui.wizard ]:	 was redirected to "https://<server>"
11-08 11:44:39:673 [ info sync.accessmanager ]:	2 "" "https://<server>/remote.php/webdav/" has X-Request-ID "b6e305f2-632d-40e0-9253-62be5830517a"
11-08 11:44:39:674 [ info sync.networkjob ]:	OCC::DetermineAuthTypeJob created for "https://<server>" + "" "OCC::OwncloudSetupWizard"
11-08 11:44:39:824 [ warning sync.networkjob.determineauthtype ]:	QUrl("https://<server>/remote.php/webdav/") was redirected to the incompatible address "https://<idp>/adfs/ls/?wa=wsignin1.0&wreply=https%3A%2F%2Fowncloud_prod_backend%2FShibboleth.sso%2FADFS&wct=2017-11-08T10%3A44%3A39Z&wtrealm=https%3A%2F%2F<server>%2FShibboleth.sso%2FADFS&wctx=cookie%3A1510137879_e55f"

[ckamm]

@SamuAlfageme The key part of the log is this:

QUrl("https://<server>/remote.php/webdav/") was redirected to the incompatible address 
"https://<idp>/adfs/ls/?wa=wsignin1.0&wreply=https%3A%2F%2Fowncloud_prod_backend%2FShibboleth.sso...

It tells me that the 2.4.0 nightly used didn't include the patch 9af6e29 which was merged three days ago. Could you try this again with the newest nightly? My expectation is that this would be detected as Basic or OAuth. Should it be detected as Shibboleth? If so, we need to adjust the url patterns used to detect it. Currently the regex applied to redirection urls to detect shibboleth is a simple SAML|wayf.

[SamuAlfageme]

@ckamm you're absolutely right, I was using a week-old nightly. 9af6e29 does solve the issue in the wizard.

@giorgosalex care to try with a newer nightly: http://download.owncloud.com/desktop/daily/ ?

EDIT: my success reproducing this was rather related to using http instead of https and not following the 301 redirection (#5954) - the 2 virtual hosts seem to have different configurations; i.e. one was basic-auth protected, the other against an IDP.

[ckamm]

@giorgosalex From your log

11-08 15:06:44:064 [ info sync.networkjob.determineauthtype ]:	Determining auth type for QUrl("https://<server>/remote.php/webdav/")
11-08 15:06:44:064 [ info sync.accessmanager ]:	2 "" "https://<server>/remote.php/webdav/" has X-Request-ID "e6d628e5-8a89-4e91-bc8c-58d1d49e62ec"
11-08 15:06:44:064 [ info sync.networkjob ]:	OCC::SimpleNetworkJob created for "https://<server>" + "" "OCC::Account"
11-08 15:06:44:064 [ info sync.accessmanager ]:	6 "PROPFIND" "https://<server>/remote.php/webdav/" has X-Request-ID "5a3f630f-2adf-4a2b-bab5-d8aa19b2b795"
11-08 15:06:44:064 [ info sync.networkjob ]:	OCC::SimpleNetworkJob created for "https://<server>" + "" "OCC::Account"
11-08 15:06:44:064 [ debug sync.networkjob ]	[ OCC::AbstractNetworkJob::slotFinished ]:	Network job OCC::CheckServerJob finished for "status.php"
11-08 15:06:44:068 [ debug sync.networkjob ]	[ OCC::AbstractNetworkJob::slotFinished ]:	Network job OCC::SimpleNetworkJob finished for ""
11-08 15:06:44:079 [ info sync.networkjob.determineauthtype ]:	Auth type for QUrl("https://<server>/remote.php/webdav/") is 0

You are using the newest code but it is indeed not figuring out the right auth type. :(

That means the GET request to "https:///remote.php/webdav/" isn't redirected in a shibboleth-y way and the PROPFIND to the same address doesn't contain any "WWW-Authenticate".

Which auth type should it detect?

Edit: Note that when I try to point my client to your server it correctly detects shibboleth auth!

[ckamm]

I've been talking to @SamuAlfageme and I think we've figured it out. The 2.3 client fell back to basic auth always, while the new client has the concept of "unknown auth type". The particular pages that are queried for the cern server actually reply 404, so the 2.4 client is confused and gives up.

Since it's a regression I'll restore the previous behavior of going with basic auth in doubt.