Errors logging in via Android client (Access Forbidden - Invalid request)

[jose1711]

Steps to reproduce

1. Use Android client to login to Nextcloud instance
2. Enter valid username + login

Expected behaviour

Successfull login event

Actual behaviour

Error
Access Forbidden
Invalid request

Server configuration

Operating system: Alpine linux

Web server: nginx

Database: mariadb

PHP version: php5-5.6.34-r0

Nextcloud version: nextcloud-13.0.1-r0

Updated from an older Nextcloud/ownCloud or fresh install: update

Where did you install Nextcloud from: official repository (edge)

Client configuration

Official Android Nextcloud app

Logs

Web server error log

Web server error log

2018/03/22 21:05:08 [notice] 26268#26268: *37 "^" matches "/login/flow/redirect", client: 192.168.0.119, server: cloud.domainxyz.com, request: "GET /login/flow/redirect?stateToken=15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q&clientIdentifier= HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:08 [notice] 26268#26268: *37 rewritten data: "/index.php/login/flow/redirect", args: "stateToken=15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q&clientIdentifier=", client: 192.168.0.119, server: cloud.domainxyz.com, request: "GET /login/flow/redirect?stateToken=15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q&clientIdentifier= HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:08 [notice] 26268#26268: *39 "^" matches "/login", client: 192.168.0.119, server: cloud.domainxyz.com, request: "GET /login?redirect_url=/login/flow/redirect%3FstateToken%3D15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q%26clientIdentifier%3D HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:08 [notice] 26268#26268: *39 rewritten data: "/index.php/login", args: "redirect_url=/login/flow/redirect%3FstateToken%3D15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q%26clientIdentifier%3D", client: 192.168.0.119, server: cloud.domainxyz.com, request: "GET /login?redirect_url=/login/flow/redirect%3FstateToken%3D15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q%26clientIdentifier%3D HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:19 [notice] 26268#26268: *47 "^" matches "/login", client: 192.168.0.119, server: cloud.domainxyz.com, request: "POST /login?redirect_url=/login/flow/redirect%3FstateToken%3D15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q%26clientIdentifier%3D HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:19 [notice] 26268#26268: *47 rewritten data: "/index.php/login", args: "redirect_url=/login/flow/redirect%3FstateToken%3D15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q%26clientIdentifier%3D", client: 192.168.0.119, server: cloud.domainxyz.com, request: "POST /login?redirect_url=/login/flow/redirect%3FstateToken%3D15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q%26clientIdentifier%3D HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:20 [notice] 26268#26268: *49 "^" matches "/login/flow/redirect", client: 192.168.0.119, server: cloud.domainxyz.com, request: "GET /login/flow/redirect?stateToken=15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q&clientIdentifier= HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:20 [notice] 26268#26268: *49 rewritten data: "/index.php/login/flow/redirect", args: "stateToken=15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q&clientIdentifier=", client: 192.168.0.119, server: cloud.domainxyz.com, request: "GET /login/flow/redirect?stateToken=15Gu5kTeRmEv0I4tsJ4ERBv5b212PaCiiVyInr9uo9pciCLhn2O194U2V6mfol0Q&clientIdentifier= HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:21 [notice] 26268#26268: *55 "^" matches "/login/flow", client: 192.168.0.119, server: cloud.domainxyz.com, request: "GET /login/flow HTTP/1.0", host: "cloud.domainxyz.com"
2018/03/22 21:05:21 [notice] 26268#26268: *55 rewritten data: "/index.php/login/flow", args: "", client: 192.168.0.119, server: cloud.domainxyz.com, request: "GET /login/flow HTTP/1.0", host: "cloud.domainxyz.com"

I suspect rewrite rules but I followed a recommended way to deploy Nextcloud server so do not really know what could be wrong. Any hint is greatly welcome.

[fabian727]

I have the same problem, but with all clients, like android-client, ubuntu-client, thunderbird for calendar and contacts (also on android)

My setup is apache2 with php-fpm, mariadb on a raspberry3 with raspbian stretch. The only same in my setup is nextcloud-13.0.1

Login with browser works as expected from computer and android

AddOn:
if I login with my admin account -> settings -> administration -> security, the table for oauth2 clients is empty. Could this have something to do with our problem?

[xduseko]

Same problem here using docker image nextcloud:13

[danb35]

I was having a similar problem, but at least my version was tied to using PHP-FPM and mpm_event in Apache. Adding the lines below to the relevant virtualhost fixed it for me:

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

[MorrisJobke]

I was having a similar problem, but at least my version was tied to using PHP-FPM and mpm_event in Apache. Adding the lines below to the relevant virtualhost fixed it for me:

This looks like the auth headers are stripped out of the request. So make sure that they are properly forwarded.

[jose1711]

following this example resolved the issue for me (nginx used as a reverse proxy): https://docs.nextcloud.com/server/11/admin_manual/configuration_server/reverse_proxy_configuration.html#example

[brucealthompson]

following this example resolved the issue for me (nginx used as a reverse proxy): https://docs.nextcloud.com/server/11/admin_manual/configuration_server/reverse_proxy_configuration.html#example

Unfortunately, this example uses the config variables "overwritehost" and "overwriteprotocol". These variables perform brute force redirects to the host / protocol defined in the variables. This means that all accesses to the Nextcloud instance will be redirected to whatever host / protocol is listed in these variables.

I have a Nextcloud instance running in my local network. I don't want requests to the nextcloud instance from client in my local network to be redirected to the proxy.

Without the "overwritehost" and "overwriteprotocol" variables, requests to the local IP of the Nextcloud instance (I use mdns for local hosts) work just fine for local nodes. With the "overwritehost" and "overwriteprotocol" variables, requests to the local IP of the Nextcloud instance are redirected out of the local network to a proxy I have set up in the cloud. The result is that uploads and downloads from clients in the local network are as slow as remote access.

The"overwritehost" and "overwriteprotocol" variables do solve the problem described in this post. Unfortunately, they have the side effect I I described above.

Is there any way to get a both local and remote access through a reverse proxy to work with Nextcloud?

[kesselb]

@brucealthompson

This is the issue tracker of Nextcloud, please do NOT use this to get answers to your questions or get help for fixing your installation. This is a place to report bugs to developers, after your server has been debugged. You can find help debugging your system on our home user forums: https://help.nextcloud.com or, if you use Nextcloud in a large organization, ask our engineers on https://portal.nextcloud.com. See also https://nextcloud.com/support for support options.

It's possible to use a reverse proxy without overwritehost and overwriteprotcol if the proxy is trusted and is forwarding the right headers. I'm not sure if this will work for your setup. Probably the people at help.nextcloud.com know.

[brucealthompson]

@kesselb

This is the issue tracker of Nextcloud, please do NOT use this to get answers to your questions or get help for fixing your installation. This is a place to report bugs to developers, after your server has been debugged. You can find help debugging your system on our home user forums:
https://help.nextcloud.com or, if you use Nextcloud in a large organization, ask our engineers on https://portal.nextcloud.com. See also https://nextcloud.com/support for support options.

I did not create this thread. I was simply responding to the comment from jose1711.

In fact, I believe there is a bug in Nextcloud that was never resolved in this thread. I will explain below.

It's possible to use a reverse proxy without overwritehost and overwriteprotcol if the proxy is trusted and is forwarding the right headers.

I believe you are partially correct in this statement. I have almost everything working without the overwritehost and overwriteprotcol variables declared. The only thing that does not work is the "Grant Access" screen of the Nextcloud apps. This is the original issue described on this thread.

I believe there is a bug in Nextcloud redirection associated with the webdav calls used in the "Grant Access" screen of the Nextcloud apps. The workaround that is described in the Nextcloud documentation is to use the overwritehost and overwriteprotcol variables to get around this issue.

I would be happy to debug this issue myself if I could get the Nextcloud apps to work with phpStorm.

I there a way to get get the Nextcloud apps to work with an xDebug style browser plugin??

[kesselb]

I there a way to get get the Nextcloud apps to work with an xDebug style browser plugin??

I think you can configure xdebug to connect with every request to a fixed remote: https://xdebug.org/docs/all_settings#remote_enable / https://xdebug.org/docs/all_settings#remote_host

[brucealthompson]

kesselb:

Your links led me to the solution for enabling xdebug unconditionally. I set this variable to enable xdebug connections unconditionally:
boolean xdebug.remote_autostart = false

And now I have gotten to the bottom of my issue.

I needed to have 127.0.0.1 as one of the values in trusted_proxies in config.php. Here is the config works for me:
'trusted_proxies' =>
array (
0 => 'proxy_name.com',
1 => 'localhost',
2 => '127.0.0.1',
),

With this and the correct reverse proxy configuration, everything works without the overwritehost and overwriteprotcol variables.