Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected authentication behavior when switching between DAV and OCS REST endpoints #12866

Open
5 of 8 tasks
aaronsegura opened this issue Mar 11, 2025 · 8 comments
Open
5 of 8 tasks

Comments

@aaronsegura
Copy link
Member

⚠️ This issue respects the following points: ⚠️

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 protected]
--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
Copy link
Contributor

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

@aaronsegura
Copy link
Member Author

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
Copy link
Contributor

susnux commented Mar 12, 2025

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
Copy link
Contributor

susnux commented Mar 12, 2025

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
Copy link
Member Author

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
Copy link
Contributor

susnux commented Mar 13, 2025

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
Copy link
Member Author

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
Copy link
Member

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

@susnux susnux transferred this issue from nextcloud/server Mar 13, 2025
@susnux susnux changed the title [Bug]: Unexpected authentication behavior when switching between DAV and OCS REST endpoints Unexpected authentication behavior when switching between DAV and OCS REST endpoints Mar 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants