macOS and iOS clients stuck in grant access loop

I have NC 15 installed currently in a snap container and a Docker container behind a nginx reverse proxy and both have the same issue. I can login via the web, but sync clients get stuck in a login/grant access loop.

On my Mac I add a new account, enter the HTTPS URL that my proxy terminates, I get a NC login prompt, I enter my credentials, they are accepted and I get a ‘Grant Access’ button. Clicking on it takes me back to the ‘Log in’ button. Pressing that takes me directly to the Grant Access button and so forth. When I login via the web and go to Settings > Security I see a token for my sync client.

I don’t see anything odd in the nginx logs or the NC logs. I started out with a Docker but then I decided to stop that and try a snap instead. Exact same issue with both systems.

While troubleshooting things, I tried using the IP to the NC host instead of my domain, hence bypassing my proxy, and I was able to connect without issue (got past grant access). The problem is that will only work if my phone/computer are on the local network, and I’d prefer to use my domain.

Any suggestions of what I can do to either troubleshoot this or fix it? I should note that my nginx proxy is running in a docker container.

4 Likes

Here are some configs:

Nginx Config

server {
    listen 80;
    server_name	nextcloud.domain.tld;
    return 301 https://$server_name$request_uri;
}

server {
    listen 		443 ssl;
    server_name 	nextcloud.domain.tld;
    ssl			on;
    ssl_certificate     /etc/letsencrypt/live/domain.tld/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain.tld/privkey.pem;

    ssl_session_cache shared:le_nginx_SSL:1m;
    ssl_session_timeout 1440m;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA DHE-RSA-AES128-SHA256 DHE-RSA-AES256-SHA256 EDH-RSA-DES-CBC3-SHA"; # managed by Certbot

    client_max_body_size 4096M;

    location /.well-known {
            alias /var/www/nextcloud.domain.tld/.well-known;
    }

    location / {
        include conf.d/proxy_set_header.inc;
        proxy_pass http://172.22.1.12:81;
    }
}

Nextcloud Config

<?php
$CONFIG = array (
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/snap/nextcloud/current/htdocs/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/snap/nextcloud/current/nextcloud/extra-apps',
      'url' => '/extra-apps',
      'writable' => true,
    ),
  ),
  'supportedDatabases' =>
  array (
    0 => 'mysql',
  ),
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => '/tmp/sockets/redis.sock',
    'port' => 0,
  ),
  'instanceid' => 'ocuko9445oth',
  'passwordsalt' => 'SALT',
  'secret' => 'PASSWORD',
  'trusted_domains' =>
  array (
    0 => 'nextcloud.domain.tld',
    1 => '172.22.1.12:81',
    2 => '172.22.1.10',
  ),
  'datadirectory' => '/var/snap/nextcloud/common/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '15.0.7.0',
  'overwrite.cli.url' => 'https://nextcloud.domain.tld',
  'overwritehost' => 'nextcloud.domain.tld',
  'overwriteprotocol' => 'http',
  'overwritewebroot' => '/',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost:/tmp/sockets/mysql.sock',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'PASSWORD',
  'installed' => true,
  'maintenance' => false,
);

As I mentioned above, my NC install lives behind a proxy. I’m running nginx inside of a Docker container. When I tail the logs while trying to log in this is what I see.

172.22.1.104 - - [13/May/2019:11:21:16 -0600] "GET /index.php/login/flow/grant?clientIdentifier=&stateToken=qdHVWU9JZFVzzdtMiU9BiNZUMvgvcKCtgfxHOm8oKIDnk34c7CW4NSKxeL4SXask HTTP/1.1" 301 185 "-" "Mozilla/5.0 (Macintosh) mirall/2.5.1final (build 20181204) (Nextcloud)" "-"
172.22.1.104 - - [13/May/2019:11:21:16 -0600] "GET /index.php/login/flow/grant?clientIdentifier=&stateToken=qdHVWU9JZFVzzdtMiU9BiNZUMvgvcKCtgfxHOm8oKIDnk34c7CW4NSKxeL4SXask HTTP/1.1" 200 7444 "-" "Mozilla/5.0 (Macintosh) mirall/2.5.1final (build 20181204) (Nextcloud)" "-"
172.22.1.104 - - [13/May/2019:11:21:16 -0600] "GET /index.php/core/js/oc.js?v=d3dc0e9b HTTP/1.1" 200 5595 "-" "Mozilla/5.0 (Macintosh) mirall/2.5.1final (build 20181204) (Nextcloud)" "-"
172.22.1.104 - - [13/May/2019:11:21:33 -0600] "POST /index.php/login/flow HTTP/1.1" 301 185 "-" "Mozilla/5.0 (Macintosh) mirall/2.5.1final (build 20181204) (Nextcloud)" "-"
172.22.1.104 - - [13/May/2019:11:21:34 -0600] "GET /index.php/login/flow HTTP/1.1" 200 7981 "-" "Mozilla/5.0 (Macintosh) mirall/2.5.1final (build 20181204) (Nextcloud)" "-"
172.22.1.104 - - [13/May/2019:11:21:34 -0600] "GET /index.php/core/js/oc.js?v=d3dc0e9b HTTP/1.1" 200 5595 "-" "Mozilla/5.0 (Macintosh) mirall/2.5.1final (build 20181204) (Nextcloud)" "-"

From what I can tell this all looks good. Not sure what else to try to get this working.

After a lot of banging, I found out the solution. I had a hunch the issue was with my proxy since I could connect directly via the IP. I used curl to identify the issue: curl -IL nextcloud.example.com. The actual issue was how NC was interacting with my proxy.

What I saw was the proxy was redirecting the http traffic to https, and then NC redirected from https://domain.tld to http://domain.tld/login, back to http. Then the proxy redirected it back to https of that domain, which is when people succeeded. I guessed this bouncing back and forth from http to https is what was causing the issue.

What ended up fixing the issue was updating my NC config so it wouldn’t keep redirecting back to http. I did this by adding the following lines to my config.

  'overwrite.cli.url' => 'https://nextcloud.example.com',
  'overwriteprotocol' => 'https',
  'trusted_proxies' => ['10.0.0.2'],

I added/updated all three lines at the same time so I’m not sure what actually solved the issue, but I think it was the overwriteprotocol is what did it. In the trusted_proxies line, add the IP of the server that is acting as the proxy in front of Nextcloud.

1 Like

Dear all,

it seems that I have the same issue as others have in this thread.
I am providing NC 17.0.2 on a kubernetes installation together with a Nginx Ingress ( I made use of the default helm chart).
The proxy is properly set up and I also added the recommended additional settings:

Blockquote
‘overwriteprotocol’ => ‘https’,
‘overwritehost’ => ‘datenspeicher.harrendorf.net’,
‘trusted_proxies’ =>
array (
0 => ‘10.96.0.1/16’,
),
‘overwrite.cli.url’ => ‘https://datenspeicher.harrendorf.net’,

Furthermore, in the Admin settings I observe that all checks have passed.
Before the usage of the above settings NC was complaining about the reverse proxy.

Nonetheless, the iOS NC app is stucked in the grant access step.
This is the output from curl:

Blockquote
HTTP/1.1 308 Permanent Redirect
Server: openresty
Date: Sun, 26 Jan 2020 14:03:36 GMT
Content-Type: text/html
Content-Length: 168
Connection: keep-alive
Location: https://datenspeicher.harrendorf.net/
HTTP/2 302
server: openresty
date: Sun, 26 Jan 2020 14:03:36 GMT
content-type: text/html; charset=UTF-8
location: https://datenspeicher.harrendorf.net/login
strict-transport-security: max-age=15724800; includeSubDomains
set-cookie: ocmu9jf036lj=d60096f9dec935a697e892ec547004d4; path=/; secure; HttpOnly
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
set-cookie: oc_sessionPassphrase=loKfS%2FczJ3HSV8R5DTK7B0yGad4qCTXQ4wWwUCEOIwt4uZaFU%2FgOxsC61fk1oBwE3xkMcwlcx%2BUTwz8mjiUpX7LsyPQ6vNrnj47Ib47vVLpnFZ2sLdeRLStIWcgPYRSY; path=/; secure; HttpOnly
content-security-policy: default-src ‘self’; script-src ‘self’ ‘nonce-MlJzb2J2a0k4RUpESkJ1YTZBRW1aYThtRzFMazdabGk2VE15NkgyZGIzbz06NnlweVBKWlNsdzhzWUdHcHZHTkhFY3BCY2hQUzNMWUpubEJuZ1UvNkhScz0=’; style-src ‘self’ ‘unsafe-inline’; frame-src *; img-src * data: blob:; font-src ‘self’ data:; media-src *; connect-src *; object-src ‘none’; base-uri ‘self’;
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: none
x-xss-protection: 1; mode=block
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
HTTP/2 200
server: openresty
date: Sun, 26 Jan 2020 14:03:36 GMT
content-type: text/html; charset=UTF-8
content-length: 5754
vary: Accept-Encoding
strict-transport-security: max-age=15724800; includeSubDomains
set-cookie: ocmu9jf036lj=9af4831611c92f1550138c00048f1b75; path=/; secure; HttpOnly
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-cache, no-store, must-revalidate
pragma: no-cache
set-cookie: oc_sessionPassphrase=ZCenO0YayK1UdIhY8jf4RZuGB%2BvbjbtMD0L93Vgnd09bHUZNdhgm%2BMZugH68HTeETlcC7gkKvc9eqA1euzc4qBQ6rxwrE5Vhgd9LeWSzyLnbdPTtMGUz0rRarqcQRvNt; path=/; secure; HttpOnly
content-security-policy: default-src ‘none’;base-uri ‘none’;manifest-src ‘self’;script-src ‘self’;style-src ‘self’ ‘unsafe-inline’;img-src ‘self’ data: blob:;font-src ‘self’ data:;connect-src ‘self’;media-src ‘self’;frame-ancestors ‘self’;worker-src ‘self’ blob:;form-action ‘self’
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: none
x-xss-protection: 1; mode=block
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
feature-policy: autoplay ‘self’;camera ‘none’;fullscreen ‘self’;geolocation ‘none’;microphone ‘none’;payment ‘none’

Does anyone has an idea, what is going wrong?

Thanks in advance

Hi @michae1ho11ey,

This is the solution. It works for me. Now, I have Nextcloud acces with my iPhone.

I’ve just added this line:

‘overwriteprotocol’ => ‘https’,

And change:

From:

‘overwrite.cli.url’ => ‘http://nextcloud.example.com’,

To:

‘overwrite.cli.url’ => ‘https://nextcloud.example.com’,

However, now I can’t connect to my Nextcloud server with my local domain because the overwriteprotocole don’t accept when I send http://mycloud.local/. The Web browser overwrite from http to https.

How I do the difference for external https connection and internal http connection ?

I use Nextcloud with docker.

Sorry for my english.

Thanks

1 Like

Thank you… I had the same idea, even looked at that part of the config.

Thanks

FYI, I had to add the ‘trusted_proxies’ I also had the other two in there, but it did not work until I added ‘trusted_proxies’.