nextcloud
Unexpected authentication behavior when switching between DAV and OCS REST endpoints
⚠️ This issue respects the following points: ⚠️
- [x] This is a bug, not a question or a configuration/webserver/proxy issue.
- [x] This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
- [x] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- [x] 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 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?
- [x] 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.
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.
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
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.
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.
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)
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.
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
