I’m using Nextcloud on two different servers. The client OS is kubuntu 19.04. The desktop client works perfectly on the connection to the Nextcloud 15 server. Yet, the very same client runs into a “Log in -> Grant Access -> Log in -> Grant Access -> Log in …” Loop against a Nextcloud 16 server.
The Nextcloud 16 server runs fine, i.e. Web Access via https is fluent. It’s just the desktop client fails to overcome the login procedure.
I tried with an application token too, but this totally break the login GUI of the desktop client. All turns to the Window background color and with just 3 widgets somewhere without any text nor image.
I cannot downgrade the server to be 15 again. What should I do?
I just found some strange message in the log flow:
unknown Mixed Content: The page at 'https://NEXTCLOUDSERVER/index.php/login/flow' was loaded over a secure connection, but contains a form that targets an insecure endpoint 'http://NEXTCLOUDSERVER/index.php/login/flow/apptoken'. This endpoint should be made available over a secure connection.
Well, the nextcloud server is of course behind a reverse proxy which is the TLS endpoint (precisely it’s a caddy Webserver). And inside a docker container. So the Nextcloud Server thinks, it runs on a http:// which is not true (well, to some point at least), yet the account registration does somehow feel annoyed by it.
Could this be the reason? Can a nextcloud server not run behind a reverse proxy?
I ve just updated to desktop 2.5.2 and test stuff not being able to reproduce, but i am using apache2
Unfortunately, i am not using nginx ( caddy is based on nginx, right ?? ).
Having a reverse proxy shouldnt be a problem.
You may need to check the proxy_passe conf…
I know nginx may need upstream ssl to work properly as a tls endpoint in reverse proxy …
@Caddy: no, this is a full new slick webserver with security in mind written in Go with out-of-the box https (based on letsencrypt) and easy to use reverse proxy settup for docker container services. (I know apache and nginx, but this one is just … uhm … to easy to setup to ignore: https://caddyserver.com) It need’s just 2 lines.
However, I strongle feel its on the nextcloud sever side and precisely this setup , since the desktop client runs smoothly with another connection to a nextcloud 15 server.
Thx for the link, I know. But the caddy server is just passing by the http request. However, it’s the TLS endpoint and the nextcloud server runs inside a docker container, without any clue of the HTTPS or HSTS for that matter.
Currently I’m scanning the server sources, and I know that the return URL for this action is in the nextcloud server in lib/private/Server.php which provides a function as getRequest() which in turn asks a ServerContainer->query(“request”). I’m not that fit in PHP, but it seems to me, that this constructs the request URL in a bad way. It obviously does not reflect the URL, which is specified in the config/config.php on the server but tries to extract its own value from the HTTP-Request.
… which is wrong.
But, again, I’m not that fit in PHP to swear on the bible about this hypthesis.
I wind up in the lib/private/AppFramework/Utility/SimpleContainer.php, which does a new ReflectionClass("Request") instantiate it and does a getRemoteAddress() on it. Totally ignoring the service URL of the nextcloud in theconfig/config.php.
Since this is run behind a reverse proxy, which changes the HTTP Header, this is a server bug on the Nextcloud side, for it cannot deduce by this method the full real URL used outside and beyond the reverse proxy.
Still, this must happen to any http instance running behind a reverse proxy. Be it Apache, nginx or Caddy… hmm, I feel somehow lost.
Could anyone from the Server department have a look at this and correct me, if I’m wrong? Thx.
I quickly browsed around the server bugs on GitHub. There are around 2000 open one and a lot of people do have severe problems with Nextcloud 16 it seems.
I’ll open up a bug report, but I do not think, that the Devs do have any time left, since it feels to me, that my situation is rather exotic (Caddy Server, Docker, Linux clients). I assume, that’s not the typical configuration of the most customers.
Also, people are still quite nice, but the plethora of bug issues over there is quite astonishing.
