Webflow Login Stuck on "Redirecting"

[tabp0le]

Details

• Nextcloud Client Version: master branch
• Client OS: ArchLinux
• Nextcloud Server Version: 13.0.2

Logs/Stacktrace

• Stacktrace Pastebin

Steps to reproduce

1. Attempt to add a new account with 2-factor auth enabled with new webflow login
2. Click "Grant Access"
3. Enter login details
4. Enter 2FA code
5. See "Redirecting" eternally

[juliusknorr]

@rullzer

[DeftNerd]

I'm having the same problem. At first I thought it was due to a corrupted nssdb because my logging kept on throwing things like

[14361:14388:0523/202121.306105:ERROR:nss_util.cc(808)] After loading Root Certs, loaded==false: NSS error code: -8018

I created a new $HOME/.pki/nssdb folder and reinitialized it using certutil -d $HOME/.pki/nssdb -N but my authentication flow is still sticking on Redirecting.

It creates the auth in Nextcloud itself, but never seems to get the token back from the webkit view.

Some log output:

[OCC::Application::setupTranslations    Using "en_US" translation
[OCC::SocketApi::SocketApi      server started, listening at  "/run/user/1000/Nextcloud/socket"
[OCC::FolderMan::FolderMan      setting remote poll timer interval to 30000 msec
[OCC::AccountManager::restoreFromLegacySettings         Migrate: restoreFromLegacySettings, checking settings group "Nextcloud"
[OCC::AccountManager::restoreFromLegacySettings         Migrate: checking old config  "/home/adam/.config/ownCloud/owncloud.cfg"
[OCC::FolderMan::setupFoldersMigration  Setup folders from  "/home/adam/.config/Nextcloud/folders" (migration)
[OCC::ClientProxy::setupQtProxyFromConfig       Set proxy configuration to use system configuration
[OCC::ownCloudGui::slotOpenSettingsDialog       No configured folders yet, starting setup wizard
[OCC::WebViewPage::WebViewPage  Time for a webview!
[OCC::OCUpdater::backgroundCheckForUpdate       Checking for available update
[OCC::AccessManager::createRequest      2 "" "https://updates.nextcloud.org/client/?client=redacted%3D%3D&version=2.5.0.0&platform=linux&oem=Nextcloud&versionsuffix=git" has X-Request-ID "c2012c1a-4159-4824-9220-3a4ba98c7bbc"
[OCC::PassiveUpdateNotifier::versionInfoArrived         Client is on latest version!
[OCC::OwncloudSetupWizard::slotSystemProxyLookupDone    No system proxy set by OS
[OCC::AccessManager::createRequest      2 "" "https://cloud.redacted.com/status.php" has X-Request-ID "f405a827-df51-490e-a7af-c2ca608574d5"
[OCC::AbstractNetworkJob::start         OCC::CheckServerJob created for "https://cloud.redacted.com" + "status.php" "OCC::OwncloudSetupWizard"
[OCC::CheckServerJob::finished  status.php returns:  QJsonDocument({"edition":"","installed":true,"maintenance":false,"needsDbUpgrade":false,"productname":"Techendeavors","version":"13.0.2.1","versionstring":"13.0.2"})   QNetworkReply::NetworkError(NoError)  Reply:  QNetworkReplyHttpImpl(0x55b16ea57c30)
[OCC::DetermineAuthTypeJob::start       Determining auth type for QUrl("https://cloud.redacted.com/remote.php/webdav/")
[OCC::AccessManager::createRequest      2 "" "https://cloud.redacted.com/remote.php/webdav/" has X-Request-ID "382e67bb-891b-42bc-a486-c6df5491a178"
[OCC::AbstractNetworkJob::start         OCC::SimpleNetworkJob created for "https://cloud.techendeavors.com" + "" "OCC::Account"
[OCC::AccessManager::createRequest      6 "PROPFIND" "https://cloud.redacted.com/remote.php/webdav/" has X-Request-ID "b3bc71b6-9af3-482d-89b5-939bf5555595"
[OCC::AbstractNetworkJob::start         OCC::SimpleNetworkJob created for "https://cloud.redacted.com" + "" "OCC::Account"
[OCC::DetermineAuthTypeJob::checkBothDone       Auth type for QUrl("https://cloud.redacted.com/remote.php/webdav/") is 3
[OCC::WebViewPage::initializePage       Url to auth at:  "https://cloud.redacted.com/index.php/login/flow"
[OCC::WebViewPageUrlSchemeHandler::requestStarted       Got user:  "adam" , server:  "https://cloud.redacted.com"
[OCC::WebViewPage::urlCatched   Got user:  "adam" , server:  "https://cloud.redacted.com"
[OCC::WebViewPage::urlCatched   URL:  "https://cloud.techendeavors.com"
[OCC::OwncloudSetupWizard::slotConnectToOCUrl   Connect to url:  "https://cloud.redacted.com"
[OCC::WebFlowCredentials::createQNAM    Get QNAM
[OCC::AccessManager::createRequest      6 "PROPFIND" "https://cloud.redacted.com/remote.php/webdav/" has X-Request-ID "8bdb3166-936f-4176-9f32-1526a15695d0"
[OCC::AbstractNetworkJob::start         OCC::PropfindJob created for "https://cloud.redacted.com" + "/" "OCC::OwncloudSetupWizard"
[OCC::WebFlowCredentials::slotFinished  request finished
[OCC::WebFlowCredentials::stillValid    Still valid?
[OCC::WebFlowCredentials::stillValid    QNetworkReply::NetworkError(AuthenticationRequiredError)
[OCC::WebFlowCredentials::stillValid    "Error transferring https://cloud.redacted.com/remote.php/webdav/ - server replied: "
[OCC::PropfindJob::finished     PROPFIND of QUrl("https://cloud.redacted.com/remote.php/webdav/") FINISHED WITH STATUS QNetworkReply::NetworkError(AuthenticationRequiredError) "Error transferring https://cloud.redacted.com/remote.php/webdav/ - server replied: "
[OCC::PropfindJob::finished     *not* successful, http result code is 401 ""
[OCC::WebFlowCredentials::stillValid    Still valid?
[OCC::WebFlowCredentials::stillValid    QNetworkReply::NetworkError(AuthenticationRequiredError)
[OCC::WebFlowCredentials::stillValid    "Error transferring https://cloud.redacted.com/remote.php/webdav/ - server replied: "

I'm using the following clients on the server running Beta channel 13.0.2:

nextcloud-client/bionic,now 2.4.0-20180523.165631~bionic1 amd64
libnextcloudsync0/bionic,now 2.4.0-20180523.165631~bionic1 amd64 

[rullzer]

Is this still happening? I had the same issues with the appimage but those got solved. Maybe you are missing some dependencies?

[marzzzello]

I have the same problem with nextcloud-client-appimage-daily from Arch User Repo. When I want to use App-Token I can't even get to the redirect page. The button "Grant access" does nothing.
On my server I use docker with a reverse-proxy (Proxy + Nextcloud).

I tested also nextcloud-desktop-git from AUR and had the same problem.
The login via the Android App works perfect.

Server log from nextcloud-client-appimage-daily:
https://hastebin.com/atewukorov.pl

Server log from Android App:
https://hastebin.com/xexohijise.coffeescript

[rullzer]

Can any of you provide me with a test account on your system?

[rullzer]

Thanks. I changed the password (just to be sure). I'll see if I can reproduce thnx.

[rullzer]

Could you post your webserver config?

It is weird. A 401 is returned but for some reason the correct Qt signal (authentication required) is never emitted.

[marzzzello]

Here is the config of the reverse-proxy (nginx)
https://hastebin.com/isevapidov.txt
The config of the nextcloud webserver is the default apache2 config from the official docker image.
I put the apache2 folder in a tar archive

[tabp0le]

@rullzer Still having this issue. Here's a testing/demo account you can use:
https://cloud.spryservers.net
u: demo
p: demodemo

[bitdegree67]

same problem here. don't know what to do.
I'm using docker image, on local is working but when i'm using with traefik isn't working. stuck on redirecting... seem it's related to reverse proxy

[tabp0le]

@bitdegree67 yeah seems to only happen in with nginx powered servers.

[bitdegree67]

same problem with kubernetes reverse proxy and with nginx reverse proxy (in traefik)

[alwinmarkcf]

@tabp0le I didn't had any problems using your demo app. Maybe you should try it in inkognito window and you have a cached redirect or sth????

[tabp0le]

@alwinmarkcf it only doesn't work with the loginflow using the built in qtweb in the desktop client. It works with Android app using new flow even. Just not desktop client.

[Grotax]

I have the same problem but I don't use a proxy I only use apache.
Simple configuration from the official documentation + TLS stuff.
The only special stuff I can think of:
Apache version: 2.4.34
http2 enabled

I did set logging to debug and found:

No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured

Full Log

[bitdegree67]

nothing new ?

[kantlivelong]

Same issue here.

[tabp0le]

@bitdegree67 i doubt you will see a fix soon. They will have to collaborate probably with the nextcloud server developer too regarding this.

If you are compiling yourself, you can use this commit to force legacy auth: SpryServers/sprycloud-desktop@b18c3ce

[ghost]

@rullzer any update on this? we're seeing the same thing, and no idea how to work around this... we're stuck unable to add the nextcloud files on one of our machines

(tested with the latest linux appimage and latest ubuntu PPA version)

[tabp0le]

@Jonast if you are able to compile yourself, I listed a work-around in my previous comment.

[camilasan]

Hi! Could any of you test this build - please make sure to have a clean configuration - https://download.nextcloud.com/desktop/daily/Windows/Nextcloud-2.5.0.61352-daily-20180904.exe?
It solved openssl/qtkeychain/credentials issues (But sadly I could never reproduce this specific issue).

[kantlivelong]

@camilasan

I just installed 2.5.0-20180904.004725~xenial1 from the PPA and it was able to migrate my existing config from 2.3.3.

I also tried to start from scratch by renaming the config directories and deleting the sync'd directory but that resulted in a crash on start.

Mint 18.3 (Ubuntu 16.04)

[tabp0le]

I'll give it a shot when I get into the office. I do not think it's related to SSL though. I think it's more related to a misinterpreted http response code.

[tabp0le]

Nope, still broken

[rullzer]

@dj-hedgehog please do. thanks!

[ypsilonkah]

When I try to log in, I am able to get past "Redirecting", but I am taken to a blank page with a blue loading bar which fills up all the way, and then nothing happens.

Client OS: Arch Linux

Looks similar to my problem (#960)

[01tot10]

Hey all!

I'm also being affected by similar behaviour.

Trying to log in with nextcloud-client on Ubuntu results in endless login loop when trying to 'Grant Access'.
Also, I tried the workaround as suggested by @the-moog, using the alternative app token pass, but unfortunately that also doesn't work since it seems Nextcloud seems to forget the full server URL when logging in.

I've tried both the latest nextcloud-client from the official PPA and the latest appImage from the website.
I'm using Ubuntu 18.04.1 LTS.
Also, I was able to use nextcloud in my previous Ubuntu LTS, 16.04 LTS, and at this very moment people using 16.04 LTS are able to connect to the very same server, using the nextcloud-client available from the PPA for 16.04 LTS.

Here are some details from the logs.

This is the "normal login" loop that I got into:
[OCC::DetermineAuthTypeJob::checkBothDone Auth type for QUrl("https://koma-server/nextcloud/remote.php/webdav/") is 3 [OCC::WebViewPage::initializePage Url to auth at: "https://koma-server/nextcloud/index.php/login/flow" [unknown Mixed Content: The page at 'https://koma-server/nextcloud/index.php/login/flow/redirect?clientIdentifier=&stateToken=BwsScoRkVet5M8Rujck0TJsFQ9KCzLGq7OOgsyWYDLLWscF0ANGkizock5xQwwbv' was loaded over a secure connection, but contains a form that targets an insecure endpoint 'http://koma-server/nextcloud/index.php/login/flow'. This endpoint should be made available over a secure connection. [unknown Mixed Content: The page at 'https://koma-server/nextcloud/index.php/login/flow/redirect?clientIdentifier=&stateToken=BwsScoRkVet5M8Rujck0TJsFQ9KCzLGq7OOgsyWYDLLWscF0ANGkizock5xQwwbv' was loaded over a secure connection, but contains a form that targets an insecure endpoint 'http://koma-server/nextcloud/index.php/login/flow'. This endpoint should be made available over a secure connection. [unknown Mixed Content: The page at 'https://koma-server/nextcloud/index.php/login/flow/redirect?clientIdentifier=&stateToken=u6deM3c4X2eSDhPNknSVRIXYm8zaju90XK6br9JqDx5qjXCncjCo6A5SdNkUUvr1' was loaded over a secure connection, but contains a form that targets an insecure endpoint 'http://koma-server/nextcloud/index.php/login/flow'. This endpoint should be made available over a secure connection.

I have tried connecting to both http:// and https:// with no avail.

Afterwards, using the app token results in the client telling:
No connection to Nextcloud at https://koma-server. Server replied "404 Not Found" to "PROPFIND https://koma-server/remote.php/webdav/"

The issue to me seems to be, that the full URL "http://koma-server/nextcloud" has become "http://koma-server" which surely doesn't respond.

The forgetting seems be happening straight after giving the access token:
[OCC::WebViewPageUrlSchemeHandler::requestStarted Got user: "otto" , server: "https://koma-server" [OCC::WebViewPage::urlCatched Got user: "otto" , server: "https://koma-server" [OCC::WebViewPage::urlCatched URL: "https://koma-server/nextcloud" [OCC::OwncloudSetupWizard::slotConnectToOCUrl Connect to url: "https://koma-server" [OCC::WebFlowCredentials::createQNAM Get QNAM [OCC::AccessManager::createRequest 6 "PROPFIND" "https://koma-server/remote.php/webdav/" has X-Request-ID "64722023-d085-4c7c-bfaf-fd853d7104a3" [OCC::AbstractNetworkJob::start OCC::PropfindJob created for "https://koma-server" + "/" "OCC::OwncloudSetupWizard"

Find attached the full log-file.
nextcloud-login.log

[rigow]

Same issue here. It does not only affect the sync client, but also sync of caldav or cardav with kdepim. Is there a workaround for the failed SAML authentication?
For the nextcloud client I get:
I get: [OCC::AbstractNetworkJob::start OCC::SimpleNetworkJob created for "https://example.org/nextcloud" + "" "OCC::Account"
[OCC::DetermineAuthTypeJob::checkBothDone Auth type for QUrl("https://example.org/nextcloud/remote.php/webdav/") is 3
[OCC::WebViewPage::initializePage Url to auth at: "https://example.org/nextcloud/index.php/login/flow"
Now if one takes that URI and copies it into the browser, firefox shows "invalid request". No, I have no whitespace user name.

[user23498723452]

I've identified the exact error that needs to be added into the code touched in #758 to fix this problem for cert issues.

Also, you should enable logging of the error number somehow. To capture something that users can report to you. See qwebengine error info

This is a showstoppper for anyone relying on direct private IP access to a publicly accessible service. And yes, it is a showstopper.

[paul-mesnilgrente]

I have the same problem.

I can see that the problem has been solved, but the next release hasn't been published, does it? The problem should be fixed in version 2.5.2. Am I right? When is it going to be released?

[01tot10]

Hey community!
Any news with this one? Still heavily affected by the bug, and can't log in from the client.
I don't know if it's bad conduct and restless bumping a topic like this, but I thought it wouldn't hurt.

[deisi]

For me it was solved by using app passwords.

[janvlug]

I'm pretty sure that I am hit by the issue with spaces in the user name. See #1001, which is not yet released.

[michidk]

Our usernames don't have spaces in the names but we use ldap. We solved it by downgrading to a previous version.

[01tot10]

For me it was solved by using app passwords.

Are you referring to App Tokens? If so, I tried it but somehow the login flow seemed to forget the server URL in the process and thus the connection wasn't successful. (See my earlier post from Jan 9th for more details)

Our usernames don't have spaces in the names but we use ldap. We solved it by downgrading to a previous version.

Yep, no spaces here neither. Haven't tried downgrading to an earlier version though! Which version did you fall back to?

Thanks for the posts everyone!

[01tot10]

... We solved it by downgrading to a previous version.

... Haven't tried downgrading to an earlier version though! Which version did you fall back to?

Ah, nevermind. Seems Ubuntu 18.04 Bionic only has one version available which is the one I have..
https://launchpad.net/~nextcloud-devs/+archive/ubuntu/client?field.series_filter=bionic

I guess downgrading is also not an option! Back to square one..

[dschmidtke]

I'm pretty sure that I am hit by the issue with spaces in the user name. See #1001, which is not yet released.

Me too, username with spaces caused the trouble. On my Ubuntu desktop, the beta version of the Nextcloud Client from the offcial beta ppa fixed this bug. The current version number is 2.5.2git. On Android, I am using stable 3.50 from the F-Droid store and it works as well. Dunno about the Windows client, though.

[user23498723452]

... We solved it by downgrading to a previous version.

... Haven't tried downgrading to an earlier version though! Which version did you fall back to?

Ah, nevermind. Seems Ubuntu 18.04 Bionic only has one version available which is the one I have..
https://launchpad.net/~nextcloud-devs/+archive/ubuntu/client?field.series_filter=bionic

I guess downgrading is also not an option! Back to square one..

I elected to install the snap that is available of 2.3.3. It works ok, except it refuses to launch at login.

NC snap client info

[paul-mesnilgrente]

This issue can be closed as the new 2.5.2 solved the issue and it has been deployed to the ppa as well.

[01tot10]

Hey hey!
I tried to 2.5.2. available from the ppa:nextcloud-devs/client, but nothing seems to be different from last time.
I can connect to our nextcloud server through my webbrowser, but not through the client.
I'm experiencing identical behaviour as described in my message from Jan 9.
I've tried logging through our server with http, https, and with the alternative app token way.
Both the normal http and https logins get stuck in an eternal login loop and the alternative app token - it seems to me - is forgetting the address in the meawhile ( "https://koma-server/nextcloud/remote.php" becomes "https://koma-server/remote.php/webdav/" ).

So, all in all, still stuck.. :/

[rullzer]

@01tot10 try to upgrade your nextcloud. It seems you are still on 13.0.4

[01tot10]

@01tot10 try to upgrade your nextcloud. It seems you are still on 13.0.4

Thanks for the reply!

Hmm, I think I should be on the latest ver!

My nextcloud client is installed from ppa:nextcloud-devs/client for Ubuntu 18.04
apt-cache policy nextcloud returns

nextcloud-client:
Installed: 2.5.2-20190319.015224bionic1
Candidate: 2.5.2-20190319.015224bionic1
Version table:
*** 2.5.2-20190319.015224~bionic1 500
500 http://ppa.launchpad.net/nextcloud-devs/client/ubuntu bionic/main amd64 Packages
100 /var/lib/dpkg/status

nextcloud --version returns

Nextcloud version 2.5.2git
Using Qt 5.9.5, built against Qt 5.9.5
Using 'OpenSSL 1.1.0g 2 Nov 2017'

As far as I'm concerned this should be the newest version!

[misch7]

Hey,

we've just released 2.6.1 RC1 which is built with Qt 5.12.5 and OpenSSL 1.1.1d on all platforms, so it features TLS 1.3 :-)

You may give it a try:
https://github.com/nextcloud/desktop/releases/tag/v2.6.1-rc1

Login (and client SSL certificates support) was fixed in the 2.6.0 release - but not with the WebView component, shown own your screenshots. Sadly the Qt webview has a lot of issues. That's why we implemented the new Login Flow v2 in v2.6.0 which is supported from NC server 16.x and up.

[misch7]

Closing this because of inactivity while the issue should by solved by using client version 2.6 in conjunction with a more recent Nextcloud server version 16 or higher (security!) ;-)

[jerome-diver]

No, it is not in relation with nextcloud client maybe. It does happen also on web ui. It is nextcloud server. As long as no one find the solution, it is useless to close an issue not resolved.

[misch7]

No, it is not in relation with nextcloud client maybe. It does happen also on web ui. It is nextcloud server. As long as no one find the solution, it is useless to close an issue not resolved.

@jerome-diver If I get your comment right: In this case you should open a server issue: https://github.com/nextcloud/server/issues