API: Password confirmation is required

ℹ️ Support
, ,
1

Creating yet another thread about that recurring topic. I want to create users by script:

curl -X POST \
    --silent \
    --header "OCS-APIRequest: true" \
    --user "$CLOUD_ADMIN_USERNAME:$CLOUD_ADMIN_PASSWORD" \
    --data userid="$member_username" \
    --data email="$member_email" \
    --data groups[]="$group_name" \
    "$cloud_url/ocs/v1.php/cloud/users?format=json"

This used to just work fine with e.g. setting CLOUD_ADMIN_PASSWORD=$(gopass show -o mynextclouduser) prior to the curl command (script).

Then Nextcloud introduced nudging everyone to use 2FA in v32 by polluting the admin overview with warnings, if 2FA enforcement was not turned on. Luckily it was ok if the enforcement was limited to e.g. the admin group.

But then with 2FA turned on for admin users, API calls stopped working. So we had to start using app passwords for that. Fine, whatever.

But in v34 this broke again, because now app passwords are considered insecure for API calls, as stated in this issue comment.

So now we are in a situation, where Nextcloud is trying to enforce 2FA, but then for important operations it is not able to use it. We need to enforce 2FA for at least some groups in order to have the warning in the overview go away, but then we need to have users with admin capability so that they can use the API, but must not have 2FA enabled for that very reason.

How can we get out of this mess?

edit: when polling /login/v2/poll and granting access in the browser, then using the returned temporary app password from the returned json also fails for the post request to create a new user :frowning:

2

And in the comment they also state:

If you like to have such a feature please open a feature request for scoped app passwords.

I don’t know if they think that such management tasks are mostly run on the server itself, so you could use the occ command for many things as well.

I think it is the best to open such a request, then you can discuss directly with the developers, if others support this feature, they can give a :+1: on github.

3

Yes, I know that I can open a feature request, but my question is about the rationale behind the change made to v34, or respectively for the current situation I described.

4

I think they always try to improve security, and since many use by default an admin account, a leaked app password has a huge impact on the security of the whole setup (not just the data of the user’s account). In theory, it would be best to be able to restrict access for certain app passwords, e.g. for you calendar client, it only needs access to you calendar (and you can revoke access to files for certain clients).

well, there was nothing in the release notes that might have prepared you:

And it is unfortunate that it broke your workflow.

But I don’t know why they disabled a working feature that potentially break workflows without having an alternative and not even documenting it in the release notes.

If you want to solve it temporarily, try to go through the changes they did, if there is an easy way of undoing it. So at least for the moment it works for you. Or if the occ command is an option for you…

5

They mention this feature:

I am not sure what that means, is password confirmation the confirmation with 2FA? Or the password itself not needed?

6

Well, that shouldn’t really be the main reason for doing it, right? It should be about the improved security, especially for accounts with admin access. :wink:

As for the actual problem, I’m afraid I don’t have a good solution for that either.

I mean, you could disable 2FA for these accounts and restrict the IP ranges from which admins are allowed to perform administrative tasks using the allowed_admin_ranges configuration parameter, and then live with the warning for the time being. But I wouldn’t necessarily recommend that, as, in my opinion, 2FA should generally be enabled, for all users who authenticate with a password these days. Especially if the instance is exposed to the internet.

7

Thanks for reminding me of the occ command. We refactored our user creation process accordingly, and it actually quite reduced its complexity :smile:

Still, I am unhappy with the situation. The user provisioning API exists and is probably in use in many processes, but with 2FA enforced, its existence no longer makes sense. There is nothing about it in the documentation, just this one “won’t fix”-comment in one of the countless despaired issues.

Yes, I am well aware that this is open source software that I am given for free. I am not at all complaining about missing or changing features. But, given that this is not a personal project but a product by a company that keeps talking big, the way decisions are (not) communicated is and has always been somewhat disappointing.

8

On the forum are mostly other users. You can open a bug report about the missing documentation in the respective repo, you can link the topics with won’t fix there. So at least, they have a chance to realize that they missed something and change that in their workflows the next time.

9

I use Nextcloud since Owncloud 3, and I have filed countless issues. My experience over the years is that such contributions by random users like me, even when carefully crafted, are usually either marked as duplicates, while the linked original hardly targets the actual problem, or they are ignored for two or three years, and then closed by a bot suggesting to re-open if the issue is still relevant.

10

From my experience, small bugs were quickly fixed but that were quite obvious things. Then if there are release candidates and it is very early on, it gets a bit more attention. If these are strange bugs, not really affecting a lot of people, then it can take a long time and can end up like in your experience.
Or it is something they think is useful and a good idea, but it takes ages to implement (and some are finally implemented).
Advantage with documentation, it is not code, it is supposed to make the manual clearer and more usable and this can be done by “normal” users quite well.

Do as you want, for me one criteria is, if this might help others (and if I have time).