Unexpected authentication behavior when switching between DAV and OCS REST endpoints

⚠️ 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.

Start with the minimal bash curl script and compare the DAV entry point at /remote.php/dav/files/admin/ with the OCS entry point at /ocs/v1.php/cloud/users. Trace how the two consecutive DAV requests affect authentication and password confirmation, then reproduce the differing request sequences with the PHP and Python clients mentioned. Done means the behavior is explained and the reported sequence no longer incorrectly requires password confirmation.