Nextcloud-Client does not work as a client anymore
Opened this issue · 45 comments
Expected behaviour
When I start the client, it should come up, ask for username and password and start to sync files with the cloud.
Actual behaviour
When I start the client, it shows a window telling me "Re-Open Browser", Firefox starts, I can log in, but the client does nothing.
Steps to reproduce
- In Kubuntu: nextcloud-client [Enter]
Client configuration
Client version: 2.6.0-20190927.150124~bionic1
Operating system: Kubuntu-Linux 18.04.3 LTS
Qt version used by client package (Linux only, see also Settings dialog):
Client package (From Nextcloud or distro) (Linux only): Qt5
Installation path of client: ?
Nextcloud version: V.1.18.0
Storage backend (external storage): RaspberryPi with NextcloudPi installed
Logs
Client logfile:
[OCC::FolderMan::setupFolders Setup folders from settings file
[OCC::ConfigFile::setupDefaultExcludeFilePaths Adding user defined ignore list to csync: "/home/crose/.config/Nextcloud/sync-exclude.lst"
[OCC::FolderMan::addFolderInternal Adding folder to Folder Map OCC::Folder(0x563ef39076e0) "1"
[OCC::FolderMan::scheduleFolder Schedule folder "1" to sync!
[OCC::FolderMan::scheduleFolder Folder is not ready to sync, not scheduled!
[OCC::ownCloudGui::slotSyncStateChange Sync state changed for folder "https://mynextcloud.de/remote.php/webdav/" : "Not yet Started"
[OCC::SyncJournalDb::checkConnect sqlite3 version "3.22.0"
[OCC::SyncJournalDb::checkConnect sqlite3 journal_mode= "wal"
[OCC::ClientProxy::setupQtProxyFromConfig Set proxy configuration to use the prefered system proxy for http tcp connections
[OCC::WebFlowCredentials::fetchFromKeychain Fetch from keychain!
[OCC::WebFlowCredentials::slotReadClientCaCertsPEMJobDone Unable to read client CA cert slot "0" "Konnte Brieftasche nicht öffnen: org.freedesktop.DBus.Error.NoReply; Message recipient disconnected from message bus without replying"
[OCC::WebFlowCredentials::slotFinished request finished
[OCC::WebFlowCredentials::stillValid QNetworkReply::NetworkError(AuthenticationRequiredError)
[OCC::WebFlowCredentials::stillValid "Error transferring https://mynextcloud.de/ocs/v2.php/core/navigation/apps?absolute=true&format=json - server replied: "
[OCC::OcsJob::finished Reply to "GET" QUrl("https://mynextcloud.de/ocs/v2.php/core/navigation/apps") (QPair("absolute","true")) has unexpected status code: 997 "{"ocs":{"meta":{"status":"failure","statuscode":997,"message":"Current user is not logged in"},"data":[]}}"
[OCC::AccountState::slotCredentialsFetched Fetched credentials for "https://mynextcloud.de" attempting to connect
[OCC::WebFlowCredentials::createQNAM Get QNAM
[OCC::ConnectionValidator::systemProxyLookupDone No system proxy set by OS
[OCC::AccessManager::createRequest 2 "" "https://mynextcloud.de/status.php" has X-Request-ID "2ca99030-df40-40c6-bedb-d2de8998ff55"
[OCC::AbstractNetworkJob::start OCC::CheckServerJob created for "https://mynextcloud.de" + "status.php" "OCC::ConnectionValidator"
[OCC::WebFlowCredentials::slotFinished request finished
[OCC::CheckServerJob::finished status.php returns: QJsonDocument({"edition":"","installed":true,"maintenance":false,"needsDbUpgrade":false,"productname":"NextCloudPi","version":"16.0.5.1","versionstring":"16.0.5"}) QNetworkReply::NetworkError(NoError) Reply: QNetworkReplyHttpImpl(0x563ef3995400)
[OCC::ConnectionValidator::slotStatusFound ** Application: ownCloud found: QUrl("https://mynextcloud.de") with version "16.0.5" ( "16.0.5.1" )
[OCC::ConnectionValidator::setAndCheckServerVersion QUrl("https://mynextcloud.de") has server version "16.0.5.1"
[OCC::AccountState::slotConnectionValidatorResult AccountState connection status change: OCC::ConnectionValidator::Status(Undefined) -> OCC::ConnectionValidator::Status(CredentialsNotReady)
[OCC::AccountState::slotInvalidCredentials Invalid credentials for "https://mynextcloud.de" asking user
[OCC::AccountState::setState AccountState state change: "Getrennt" -> "Zugangsdaten werden abgefragt"
[OCC::FolderMan::slotAccountStateChanged Account "crose@mynextcloud.de" disconnected or paused, terminating or descheduling sync folders
[OCC::AccessManager::createRequest 4 "" "https://mynextcloud.de/index.php/login/v2" has X-Request-ID "460adaaa-4feb-43e3-8f4e-cc58178498fd"
[OCC::AbstractNetworkJob::start OCC::SimpleNetworkJob created for "https://mynextcloud.de" + "" "OCC::Account"
[OCC::WebFlowCredentials::slotFinished request finished
[OCC::Flow2Auth::openBrowser()::<lambda setting remote poll timer interval to 5000 msec
[OCC::OCUpdater::backgroundCheckForUpdate Checking for available update
[OCC::AccessManager::createRequest 2 "" "https://updates.nextcloud.org/client/?client=RGlzdHJpYnV0b3IgSUQ6CVVidW50dQpEZXNjcmlwdGlvbjoJVWJ1bnR1IDE4LjA0LjMgTFRTClJlbGVhc2U6CTE4LjA0CkNvZGVuYW1lOgliaW9uaWMK&version=2.6.0.0&platform=linux&oem=Nextcloud&versionsuffix=git" has X-Request-ID "d882a384-0b65-4075-82ec-e7d6ffe3dcf0"
[OCC::PassiveUpdateNotifier::versionInfoArrived Client is on latest version!
Same issue here.
- OS is Ubuntu 19.04
- client version Nextcloud-2.6.0-x86_64.AppImage
- server version 17.0.0.9
- docker with nginx reverse proxy
- 'overwriteprotocol' => 'https' is set
Access with Browser and ios apps work with https, also the Nextcloud-2.3.3-x86_64.AppImage.
Client version 2.6.0 starts the Nexcloud Connection Wizard, Re-open Browser and login are working, granting access leads to nothing.
docker logs:
172.31.0.1 - - [07/Oct/2019:14:03:19 +0000] "GET /status.php HTTP/1.0" 200 1548 "-" "Mozilla/5.0 (Linux) mirall/2.6.0stable (build 20190927) (Nextcloud)" 172.31.0.1 - - [07/Oct/2019:14:03:19 +0000] "GET /remote.php/webdav/ HTTP/1.0" 401 1553 "-" "Mozilla/5.0 (Linux) mirall/2.6.0stable (build 20190927) (Nextcloud)" 172.31.0.1 - - [07/Oct/2019:14:03:19 +0000] "PROPFIND /remote.php/webdav/ HTTP/1.0" 401 1547 "-" "Mozilla/5.0 (Linux) mirall/2.6.0stable (build 20190927) (Nextcloud)" 172.31.0.1 - - [07/Oct/2019:14:03:19 +0000] "POST /index.php/login/v2 HTTP/1.0" 200 1107 "-" "Mozilla/5.0 (Linux) mirall/2.6.0stable (build 20190927) (Nextcloud)"
Switching back to 2.3.3 works again. 2.5.2 does not work either.
Nice idea! And thank you for your answer.
Could you please describe how you managed to "downgrade" back to 2.3.3? For me it seems that the package is not in the ppa any more.
I use the appimage.
I wonder why the new 2.6.0 version starts the connection wizard and does not use the already configured connection from the predecessor.
login_v2.6.log
Same here; it opens the login flow dialog by opening my default browser (Firefox), and when I click on "Grant Access", the button does nothing ...
Also tried to logout via desktop client and re-login, but also doesn't work.
See attached log for details.
Same here, had to login via 'Reopen Browser' like some barbarian, instead of an App token option.
I just tried the daily/Linux/Nextcloud-2.7.0.20191017-daily-x86_64.AppImage from today, and unfortunately I'm still not able to login into my Nextcloud instance. As soon as the browser opens and I click on the "Login" ("Anmelden") -> "Grant access" ("Zugriff gewähren" in German) nothing happens, in other words, the button click on "Grant access" (in the browser window) does nothing. I also tried clearing all my cookies and stuff; also running the same with Chromium shows no effect (Firefox is my default browser). Any ideas?
Update: Just tried with a new dummy user I just created on my Nextcloud instance, cleared all cookie data in my web browser -- same effect, no login via desktop client possible, stuck at the disfunct "Grant access" button.
Update 2: Digging further, when opening the Firefox Development Tools, in the console I see a "Content Security Policy: The page’s settings blocked the loading of a resource at http://myserver.de/index.php/login/v2/grant (“form-action”)" message every time I click on the "Grant access" button.
Disabling all my extensions such as uBlock and uMatrix did not help either though ...
Did a bit more research, but as I'm not a web developer, this just is a guess: My server uses Let's Encrypt with https, so the server address is https://nextcloud.myserver.de -- the script (see message above) it tries to load when clicking on the "Grant access" buttons wants to load a Javascript file from http (note the missing 's', so without TLS) -- could this be the reason?
Found a work around, which I do not consider safe though: In Firefox, open about:config and disable security.csp.enable -- after logging out and trying to log in again, the "Grant access" button finally works. This does the trick for me, at least for now ... any plans to fix this properly? Don't want to run my browser with CSP disabled all the time.
Found another workaround. It replaces http:// by https:// in the form.action attribute via Developer Tools Console:
document.querySelector("form").action = document.querySelector("form").action.replace("http://", "https://")
This way you don't have to disable CSP.
Same issue here, btw.
- Client OS is Windows 10
- client version 2.6.0stable-Win64 (build 20190927)
- server version 17.0.0
- docker with nginx reverse proxy
With security.csp disabled granting access works. The new sync client appears in web interface in settings | devices & sessions. But: the desktop client stays logged off with the only option to create a new account, which leads again to the connection wizard.
Hey guys, I have solved the problem like the following. It worked for me with Client version 2.6 on MacOS and on iOS Phone. Docker with nextcloud:apache.:
- Add a file with the name under path
/var/www/nextcloud/config/: extra.config.php - Fill it with this block
<?php
$CONFIG = array (
'overwrite.cli.url' => 'https://nextcloud.myserver.net',
'overwriteprotocol' => 'https',
# 'installed' => true, );
);
- Restart you nextcloud & enjoy it
My case is nextcloud open URL in default browser and get 403.
https://[host]/login/v2/Flow/[a-verylong-token]
https://[hostname]/login/v2/flow/jgPNbrdZ........u7mpMREj...12ND2y25......EBnJcW1ijqqhMA044YvcotDVmiuOB1BkRRlKnojCA9R
At the same time, Nextcloud client shows:
Environment:
client: Nextcloud-2.6.0-x86_64.AppImage on Kubuntu 19.10
server: V16.05 nginx + php 7.2 native environment (server ubuntu 18.04)
Workaround: downgrade client to lower version:
client: Nextcloud-2.5.3-x86_64.AppImage
download old version from here:
https://download.nextcloud.com/desktop/releases/Linux/
After downgrade everything works fine.
PS: problematic client 2.6.0 works with server V15 without any problem.
Hm ...still no official answer from the devs? I wonder how we're supposed to "officially" work around this without disabling CSP completely.
@fbau3r Your work around also works for me here, cheers for that!
Hm ...still no official answer from the devs? I wonder how we're supposed to "officially" work around this without disabling CSP completely.
@fbau3r Your work around also works for me here, cheers for that!
You don't need the workaround, try my method above
@mmouselli I also consider your extra config as a work around until this isn't officially fixed ;-) As we have more than one option to get this back working, the question still remains how and when they will fix it.
Found a work around, which I do not consider safe though: In Firefox, open about:config and disable security.csp.enable -- after logging out and trying to log in again, the "Grant access" button finally works. This does the trick for me, at least for now ... any plans to fix this properly? Don't want to run my browser with CSP disabled all the time.
This workaround worked for me. Don't you only once disable it for logging in with the client and then enable it again? I did so.
Does anyone know the equivalent option for Chrome?
Another working workaround is to replace the http with https in the inspector in the developer tools of Firefox. In Chrome it does also work this way.
This URL seems to be generated in core/templates/loginflowv2/grant.php
So now my question is: Why is it generated without https?
Same issue here with client 2.6.1 on MacOS.
After I modify the URL to https I'm able to click the "grant" button but my client doesn't do anything.
For MacOS I had to downgrade the client to 2.3.3 from https://download.nextcloud.com/desktop/releases/Mac/Installer/ .
My server is based on docker-compose using this official (?) example https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/with-nginx-proxy/postgres/apache
Yes, the issue is the same in version 2.6.1 on Ubuntu. Only downgrade to 2.3.3 helps.
Same situation over here with Client 2.6.0 on Manjaro Linux and Server 17.0 on Ubuntu.
Downgrade on 2.5.3 works fine.
Indeed also version 2.5.3 seems to work on Ubuntu for me.
As mentioned by @fbau3r, your server is probably not configured correctly. Nextcloud tries to detect if it should use http or https, but that detection isn't perfect (especially if you're using a reverse proxy) which is why the 'overwrite.cli.url' and 'overwriteprotocol' configuration options exist. Once you've set those up correctly (as indicated by @mmouselli) you should be able to use the current client without any difficulty or workarounds. (@x86dev setting these configuration options isn't a "workaround"; this is giving Nextcloud the information it needs to be configured correctly.)
To the OP, please try following @mmouselli 's suggestion and see if that solves your problem.
Hello,
We have the same problem here even if we have a good configuration :
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://our-nextcloud-url',
@RussellAult
I have changed the configuration as indicated by @mmouselli. But the problem is still the same. After "Grant access" the client wont sync.
Edit:
It seems to work.
My mistake was to close the Popup window before clicking on "Grant Access"
If I don't close it, it will close automatically after I clicked on "Grant Access" and the client starts syncing.
All in all it could be a little bit more clear. I thought if the browser ask for my credentials I don't need the pop up anymore. So maybe add a little hint like "don't close this window until you are successfully logged in"
We found the origin of our problem. We have user_saml configured with mod_auth_cas (apache). According to the documentation, we have set this apache config :
CASVersion 2
CASLoginURL https://cas.company.com/cas/login
CASValidateURL cas.company.com/cas/serviceValidate
<Location "/index.php/login">
AuthType CAS
AuthName "CAS Authentication"
require valid-user
</Location>
<Location "/index.php/apps/user_saml/saml/login">
AuthType CAS
AuthName "CAS Authentication"
require valid-user
</Location>
When I try to make a curl on the login/v2 URL, I'm redirected and don't have the token json, as expected (https://docs.nextcloud.com/server/latest/developer_manual/client_apis/LoginFlow/index.html#login-flow-v2) because I'm redirected to my CAS server :
$ curl -X POST https://my-nextcloud.fr/index.php/login/v2
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://auth.univ.fr/login?service=http%3a%2f%2fmy-nextcloud.fr%2findex.php%2flogin%2fv2">here</a>.</p>
</body></html>
We need to remove this part in the apache configuration in order to make the client work again :
<Location "/index.php/login">
AuthType CAS
AuthName "CAS Authentication"
require valid-user
</Location>
I still don't know if we can remove this configuration forever, it seems to be useless but I'll keep testing.
In my case there´s a http instead of the https of the URL in POST address of the form. Workaround: edit the html with developer tools in browser and it works.
But I don´t know where it comes from. All url are with https, 'overwrite.cli.url' as well.
Yep, there was a HTTP URL instead of HTTPS in the POST form. The workaround of changing that in the developer tools worked like a charm. Thanks everyone!
We have same problem until upgraded the server version to 16 at production and 17 at staging.
Clients using versions higher than 2.5.3 stopped working and tried all solutions described at this issue, but no results.
We use CAS (casino) with nginx.
Maybe this is proxy related.
Testing with NC18, client v. 2.6.2 and CAS authentication it fails when the client is on a machine behind an authenticating proxy. On a similar machine not behind a proxy die client login works without any problems.
Edit:
Without CAS the clients behind the proxy also work fine.
Another workaround, for what it's worth ;-)
I could authenticate a client on a machine (NC18, client v. 2.6.2 and CAS authentication) by:
- Start the client setup an the machine behind the proxy where client will be running
- Copy the link that the client generates
- Call the link in a browser that is not behind the proxy
- Confirm the login
The client behind the proxy works!!!!
Same problem here on Kubuntu 18.04 LTS with client-version 2.6.3 from PPA and server version 17.0.2 (Image from Docker Hub, using with kubernetes traefik ingress controller as a ReverseProxy)
I have also had the problem with Kubuntu 18.04 LTS with client-version 2.6.3 from PPA and server version 17.0.0 (Image from Docker Hub, using with kubernetes traefik ingress controller as a ReverseProxy)
Deleting ~/.config/Nextcloud/nextcloud.cfg on the client allowed me to re-login here, so the problem is fixed. However, this does not work in my setup with server version 17.0.2 .
Is there any solution to fix this in the server docker image?
//edited: It also could be that the different version of the traefik ingress controller makes the difference here...
Same "problem", in my docker swarm with a reverse proxy.
Resolved after applying mmouselli's suggested method, but directly in config/config.php
Really looks like a server issue indeed. In any case resetting the milestone since it didn't make it for 2.62.
I still have this problem. A description:
I use NextCloud 20.0.4, I use Docker compose and the Traefik proxy. I have added
`overwriteprotocol` => `https`
Allthough nobody specifies where, I tried several positions, currenty it is here (at the very start of the file):
?php
$CONFIG = array (
'htaccess.RewriteBase' => '/',
'memcache.local' => '\\OC\\Memcache\\APCu',
`overwriteprotocol` => `https`,
'apps_paths' =>
array (
I also changed
'overwrite.cli.url' => 'https://cloud.mydomain.nl',
I set Traefik to reroute http to https (this works). I tested client 2.6 from the Ubuntu 20.04 repo's and also the AppImage (3.1.1). Nothing worked. Any other suggestions? Is there perhaps a way to set up the sync client with an app-password? I do have TOTP 2fa enabled.
I just tested the config based http>https and the Traefik one, they both work separately from each other, still, the access granting does not work.
Thanx,
Freek
Edit, disabling security.csp.enable temporarily in FireFox, allowed me get through the access procedure.
Still broken with nextcloud server v21 (docker-compose setup with the current latest image, behind an apache reverse proxy) and client v3.1.
EDIT: an alternative to temporarily disabling security.scp.enable that should work in any browser is to manually edit the URL that the "Grant" button submits to in the HTML code of the grant page. Just making it https instead of http worked for me.
EDIT2: had to switch to the owncloud client in the end (works out of the box) because the nextlcloud client would ask me to grant access at every new login
This issue is still existing in v22
I'm having this issue:
The polling URL does not start with HTTPS despite login URL started with HTTPS. Login will not be possible because this might be a security issue. Please contact your administrator.
Server version V21.0.3
Client version 3.5.0 appimage
Pop!_OS, note that the Gnome Online Accounts thing connected without issue. My android is also connected without issue.
Very surprised this is a problem...
[Edit: Downloaded v2.3.3 of the appimage client. Connect no problems....]
[Edit2: v2.3.3 failed after restart. I found that there is a .deb in the Pop! store, downloaded and installed that. Works like a charm.
Moral of the story: Avoid appimage (that was always my thought to begin with, this just cements that thought.)]
@maxtimbo Your problem is probably unrelated to the original issue. Please open a new issue. Having said that, this error should only pop up if the login URL started with https and the URL that is used for polling starts with http instead of https. This can lead to security issues. Either your server is misconfigured someone is tricking you or we have a bug. So please open a new issue and post your logs :)
@kubuntu-fan can you test with the latest release to see if you still reproduce ?
in case the bug is fixed, please close this issue
@mgallien
Recently switched to Ubuntu-Server 21.04 LTS with the actual snap of nextcloud, using Client-Version 3.2.4. I had to log in once via Browser; now it automatically logs in every time my desktop computer starts.
So, for me it is solved.
@kubuntu-fan thanks for the reply
closing it
if somebody experience troubles I would really suggest to either ask on the Nextcloud forum or open a new issue