Unexpected authentication behavior when switching between DAV and OCS REST endpoints

[aaronsegura]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Howdy!

I'm running into some weird behavior when switching between DAV and OCS REST endpoints. After issuing a couple of DAV requests and then attempting to create a user via the OCS endpoint, I get "[403] Password confirmation is required". The session is created and all of the calls happen within a few seconds of each other, not 30 minutes later.

Here's the weird part: it only happens if I run two DAV operations back-to-back and then try to create the user.

Here is a minimal bash script using curl to reproduce the error:

COOKIE_FILE=/tmp/CURL_COOKIES && rm -f $COOKIE_FILE
COOKIES="-c $COOKIE_FILE -b $COOKIE_FILE"
AUTH='-u admin:admin'
USER_DATA='--data userid=test_user
--data displayName=TestUser
--data email=test@example.com
--data quota=none
--data password=SuperC00lUniquePassw0rd
--data language=en
--data format=json'
OCS_HEADER='-H OCS-APIRequest:true'
HOST='http://localhost:8181/'

list_directory() {
    curl -s -XPROPFIND $AUTH $COOKIES $HOST/remote.php/dav/files/admin/ > /dev/null
}

create_user() {
    curl $AUTH $COOKIES $OCS_HEADER $USER_DATA $HOST/ocs/v1.php/cloud/users; echo
}

list_directory
list_directory
create_user

I originally found this behavior by running two PUT requests against the DAV interface to upload files before creating a user, so this isn't limited to just PROPFIND operations.

Running list_directory only once followed by create_user behaves as expected.

Oddly, this variation succeeds for all three create_user calls:

create_user
create_user
list_directory
list_directory
create_user

but this one fails on the 2nd create_user call:

create_user
list_directory
list_directory
create_user

When I say "succeeds", I mean I get a User already exists message instead of a Password confirmation required message.

This affects every version of Nextcloud I have tried: 29, 30, 31, master.

Thanks in advance for your time and attention.

Steps to reproduce

See above

Expected behavior

See above.

Nextcloud Server version

master

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "apps_paths": [
            {
                "path": "\/var\/www\/nextcloud\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/nextcloud\/apps2",
                "url": "\/apps2",
                "writable": true
            }
        ],
        "loglevel": 0,
        "debug": true,
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost:8443"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "32.0.0.0",
        "overwrite.cli.url": "https:\/\/localhost:8443",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "updater.release.channel": "git",
        "installed": true
    }
}

List of activated Apps

Enabled:
  - circles: 32.0.0-dev.0
  - cloud_federation_api: 1.15.0
  - comments: 1.22.0
  - contactsinteraction: 1.13.0
  - dashboard: 7.12.0
  - dav: 1.34.0
  - federatedfilesharing: 1.22.0
  - federation: 1.22.0
  - files: 2.4.0
  - files_reminders: 1.5.0
  - files_sharing: 1.24.0
  - files_trashbin: 1.22.0
  - files_versions: 1.25.0
  - groupfolders: 20.0.0-dev.0
  - lookup_server_connector: 1.20.0
  - oauth2: 1.20.0
  - profile: 1.1.0
  - provisioning_api: 1.22.0
  - settings: 1.15.0
  - sharebymail: 1.22.0
  - systemtags: 1.22.0
  - theming: 2.7.0
  - twofactor_backupcodes: 1.21.0
  - updatenotification: 1.22.0
  - user_status: 1.12.0
  - viewer: 4.0.0
  - weather_status: 1.12.0
  - webhook_listeners: 1.3.0
  - workflowengine: 2.14.0
Disabled:
  - admin_audit: 1.22.0
  - calendar: 5.1.2
  - circles-old: 0.21.4
  - contacts: 7.0.1
  - encryption: 2.20.0
  - files_external: 1.24.0
  - mail: 4.2.3
  - notes: 4.11.0
  - richdocuments: 8.5.4
  - richdocumentscode: 24.4.1204
  - spreed: 20.1.4
  - testing: 1.22.0
  - user_ldap: 1.23.0 (installed 1.23.0)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No relevant logs generated.

Additional info

This behavior is also exhibited using python httpx and aiohttp libraries.

[SystemKeeper]

Does it work if you leave out the cookies in create_user?

[aaronsegura]

Does it work if you leave out the cookies in create_user?

Yes, it does. That's how I work around the issue currently. Sorry, I should have mentioned this in my original report.

[susnux]

then it is more or less expected behavior.
Because if you authenticate on the DAV endpoint your session is bound to DAV app and thus the cookie authentication on OCS will fail.
Thats why without cookies it works

[susnux]

Also it is not recommended to use the password. If you use an apptoken instead it will also work with cookies enabled as the app token has priority over the cookies.

[aaronsegura]

then it is more or less expected behavior. Because if you authenticate on the DAV endpoint your session is bound to DAV app and thus the cookie authentication on OCS will fail. Thats why without cookies it works

It might be expected, but is it intended? This seems like an unintended side-effect rather than something that would be designed to function this way, especially considering how inconsistent the results are.

[susnux]

Yes it is intended that there is a DAV exclusive session.

So you have those options:

• Always use cookie auth and do not sent basic auth headers (thats what web ui is doing)
• Always use basic auth but do not sent any cookies (not recommended)
• Always use token auth (app password with Auth: Bearer ...) with or without cookies (recommended)

[aaronsegura]

Thank you for the explanation.

Should the OCS authentication layer possibly fall back to checking for credentials supplied via basic auth for password confirmation when needed? It would save time over having to submit another request if the user is already providing the password it's looking to confirm.

Yes it is intended that there is a DAV exclusive session.

Is this documented somewhere? Would have saved me quite a bit of time had I seen it.

Always use token auth (app password with Auth: Bearer ...) with or without cookies (recommended)

I have added this as optional functionality to my project and it works as expected. Thank you.

[joshtrichards]

Is this documented somewhere? Would have saved me quite a bit of time had I seen it.

Not sure, but there's always room for improvement. ;-)

If you see a good spot for it in either the Dev Manual or Admin Manual (https://docs.nextcloud.com) maybe you can trigger an addition (by either submitting a PR or opening an Issue with some preliminary language that would have helped you)?

https://github.com/nextcloud/documentation