Nginx login fails with auth_base

loratera commented 5 years ago

Steps to reproduce

NGINX Server Setup, with "auth_basic" activated on root domain (example.com).
Nextcloud at subdomain (example.com/nextcloud), but under this subdomain "auth_basic off"
Go from example.com (after verification) to example.com/nextcloud

Expected behaviour

Login appears and it's possible to login.

Actual behaviour

Login appears after a long time, and Brute-Force-Protection prevented further login attempts. But user haven't even seen the login page until BFP takes place. Nextcloud seems to use the login (cookie?) from the previously authenticated auth_basic module automatically.

If example,com/nextcloud is called directly, without previously verification on root domain, everything is working as expected.

Server configuration

Operating system: Raspbian GNU/Linux 9 (stretch) Web server: nginx/1.10.3 Database: 10.1.37-MariaDB-0+deb9u1 Raspbian 9.0 PHP version: PHP 7.0.33-0+deb9u1 Nextcloud version: (see Nextcloud admin page) 15.0.5 Updated from an older Nextcloud/ownCloud or fresh install: Fresh install of Nextcloud 15 Where did you install Nextcloud from: source Signing status:

Signing status

``` No errors have been found. ```

List of activated apps:

App list

``` list Enabled: - accessibility: 1.1.0 - activity: 2.8.2 - calendar: 1.6.4 - cloud_federation_api: 0.1.0 - comments: 1.5.0 - contacts: 3.0.3 - dav: 1.8.1 - federatedfilesharing: 1.5.0 - federation: 1.5.0 - files: 1.10.0 - files_pdfviewer: 1.4.0 - files_sharing: 1.7.0 - files_texteditor: 2.7.0 - files_trashbin: 1.5.0 - files_versions: 1.8.0 - files_videoplayer: 1.4.0 - firstrunwizard: 2.4.0 - gallery: 18.2.0 - logreader: 2.0.0 - lookup_server_connector: 1.3.0 - nextcloud_announcements: 1.4.0 - notifications: 2.3.0 - oauth2: 1.3.0 - password_policy: 1.5.0 - provisioning_api: 1.5.0 - serverinfo: 1.5.0 - sharebymail: 1.5.0 - spreed: 5.0.2 - support: 1.0.0 - survey_client: 1.3.0 - systemtags: 1.5.0 - theming: 1.6.0 - twofactor_backupcodes: 1.4.1 - updatenotification: 1.5.0 - workflowengine: 1.5.0 Disabled: - admin_audit - encryption - files_external - user_ldap ```

Nextcloud configuration:

Config report

``` ig:list system { "system": { "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "example.com" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "version": "15.0.5.3", "overwrite.cli.url": "https:\/\/example.com\/nextcloud", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "maintenance": false, "loglevel": 2 } } ```

Are you using external storage, if yes which one: local/smb/sftp/... no Are you using encryption: yes/no no Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/... no

Client configuration

Browser: Mozilla Firefox Operating system: Windows

Logs

Web server error log

``` Insert your webserver log here ```

Nextcloud log (data/nextcloud.log)

Nextcloud log

``` {"reqId":"PnzqQkuYYIElE4zjycnv","level":2,"time":"2019-03-04T18:28:00+00:00","remoteAddr":"192.168.0.1","user":"--","app":"core","method":"POST","url":"\/nextcloud\/login","message":"Login failed: 'secretUser' (Remote IP: '192.168.0.1')","userAgent":"Mozilla\/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko\/20100101 Firefox\/60.0","version":"15.0.5.3"} ```

Browser log

``` Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ... ```

kesselb commented 5 years ago

Make sense somehow ;) If nginx expose HTTP_AUTHORIZATION to fastcgi nextcloud tries to use this credentials to login the user and brute force protection might be triggered.

I'm not sure if there is a way to turn this off. I assume you use the same server block for example.com and example.com/nextcloud. I would try to extend the location block for /nextcloud and add something like

fastcgi_param HTTP_AUTHORIZATION '';

Here the code https://github.com/nextcloud/server/blob/0cfcccee29652c83e6c898bc487fe09bb54e0c22/lib/base.php#L1034

I think the cleanest solution would be a subdomain (nextcloud.example.com).

loratera commented 5 years ago

Thx, for you're reply. That's a good workaround, I have tested it and it works quite well trough the weblogin, but then other clients fail to connect (like Webdav or nextcloud android client). It seems they rely on this header. Probably that's the reason why it is implemented in that way :).

For me then the only solution is to move to a subdomain. Is there any change that this will be changed in the future?

kesselb commented 5 years ago

For me then the only solution is to move to a subdomain. Is there any change that this will be changed in the future?

I don't think so. Its a common problem that you cannot stack (http) authorization methods. But let's ask the experts @rullzer @tobiasKaminsky

ghost commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

nextcloud / server