[API] Unable to save user with using API endpoint

[kphk]

We are using API /api/public/v1/users to create user and grant permission to app
It was working fine, until upgrade to 2.4.31. (not sure if this related to version upgrade)

the request body

{
    "email": "someone@email.com",
    "firstName": "Some",
    "lastName": "One",
    "password": "secret_password",
    "status": "active",
    "forceResetPassword": false,
    "builder": {
        "global": false
    },
    "admin": {
        "global": false
    },
    "roles": {
        "app_12345678901234567890": "BASIC"
    }
}

the error return from API call

{
    "message": "Unable to save user - Unavailable",
    "status": 400
}

log from the app

ERROR [1679366387126] (31 on 5d964c70b1ce): Unable to save user - Unavailable
    BadRequestError: Unable to save user - Unavailable
        at Object.throw (/app/node_modules/koa/lib/context.js:97:11)
        at /app/dist/utilities/workerRequests.js:61:26
        at Generator.next (<anonymous>)
        at fulfilled (/app/dist/utilities/workerRequests.js:5:58)
        at runMicrotasks (<anonymous>)
        at processTicksAndRejections (internal/process/task_queues.js:95:5)
[correlationId=4e040388-c9ec-4697-93b6-caf7cb85f81f] [tenantId=default] Trace: [correlationId=4e040388-c9ec-4697-93b6-caf7cb85f81f] [tenantId=default] BadRequestError: Unable to save user - Unavailable
    at Object.throw (/app/node_modules/koa/lib/context.js:97:11)
    at /app/dist/utilities/workerRequests.js:61:26
    at Generator.next (<anonymous>)
    at fulfilled (/app/dist/utilities/workerRequests.js:5:58)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at print (/app/node_modules/@budibase/backend-core/dist/src/middleware/logging.js:86:9)
    at console.trace (/app/node_modules/@budibase/backend-core/dist/src/middleware/logging.js:97:33)
    at /app/node_modules/@budibase/backend-core/dist/src/middleware/errorHandling.js:51:25
    at Generator.throw (<anonymous>)
    at rejected (/app/node_modules/@budibase/backend-core/dist/src/middleware/errorHandling.js:29:65)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
INFO  [1679366387127] (31 on 5d964c70b1ce): request completed
    res: {
      "statusCode": 400,
      "headers": {
        "vary": "Accept-Encoding",
        "x-budibase-tenant-id": "default",
        "x-ratelimit-limit": "10",
        "x-ratelimit-remaining": "9",
        "x-ratelimit-reset": "1679366389",
        "content-type": "application/json; charset=utf-8",
        "content-length": "60"
      }
    }
    responseTime: 119
    req: {
      "id": "536ba38c-849b-4302-94fd-22d27f663a66",
      "method": "POST",
      "url": "/api/public/v1/users",
      "headers": {
        "connection": "upgrade",
        "x-real-ip": "172.20.0.1",
        "x-forwarded-for": "x.x.x.x",
        "host": "budibase.mycompany.com",
        "content-length": "375",
        "x-forwarded-proto": "https",
        "x-budibase-api-key": "x-budibase-api-key-xxxxxxxxxxxxxxxxx",
        "content-type": "application/json",
        "user-agent": "PostmanRuntime/7.31.3",
        "accept": "*/*",
        "postman-token": "cd620863-2149-4015-9db3-56c97d7418cf",
        "accept-encoding": "gzip, deflate, br",
        "cookie": "budibase:currentapp=some_token_masked"
      },
      "remoteAddress": "::ffff:172.20.0.9",
      "remotePort": 42600
    }

captured the log from worker

ERROR [1679366321055] (30 on 055f8a14a0df): Unavailable
    BadRequestError: Unavailable
        at Object.throw (/app/node_modules/koa/lib/context.js:97:11)
        at /app/dist/api/controllers/global/users.js:60:18
        at Generator.throw (<anonymous>)
        at rejected (/app/dist/api/controllers/global/users.js:29:65)
        at runMicrotasks (<anonymous>)
        at processTicksAndRejections (internal/process/task_queues.js:95:5)
[correlationId=a466e193-d5ee-4e6b-be94-3163793fd590] [tenantId=default] Trace: [correlationId=a466e193-d5ee-4e6b-be94-3163793fd590] [tenantId=default] BadRequestError: Unavailable
    at Object.throw (/app/node_modules/koa/lib/context.js:97:11)
    at /app/dist/api/controllers/global/users.js:60:18
    at Generator.throw (<anonymous>)
    at rejected (/app/dist/api/controllers/global/users.js:29:65)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at print (/app/node_modules/@budibase/backend-core/dist/src/middleware/logging.js:86:9)
    at console.trace (/app/node_modules/@budibase/backend-core/dist/src/middleware/logging.js:97:33)
    at /app/node_modules/@budibase/backend-core/dist/src/middleware/errorHandling.js:51:25
    at Generator.throw (<anonymous>)
    at rejected (/app/node_modules/@budibase/backend-core/dist/src/middleware/errorHandling.js:29:65)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

Any idea, thanks a lot

BTW, other read operation API call works fine, e.g. search users or search applications

[melohagan]

Hey @kphk

If you trying to create a brand new user, are you certain that the user doesn't already exist? I.e. the email someone@email.com isn't in use by an existing user?

You can use the PUT endpoint with the user ID to update an existing user.

[marian001]

I only tried changing roles. I have one app which should be accessible to each registered user. So I'm automatically triggering assignment of BASIC role to each new user (i.e. user without any role assignment for my app). This is to avoid delays with making the assignment manually. Without this we're worsening user experience for our users...

To stop people from getting around user limits, there should be some check done after the PUT call with roles parameter is made, to see whether the user is authorized to make specific change. Not disabling the whole use of roles parameter and disqualifying everybody who uses it for legitimate purposes...

According to documentation builder and admin parameters are also available only for Business/Enterprise licenses:

[shogunpurple]

Hi @marian001

The main reason this restriction was brought in was to avoid using the public API to work around our user groups feature, which is paid. When you invite a user, you can assign them to user groups so they already have default access.

To stop people from getting around user limits, there should be some check done after the PUT call with roles parameter is made, to see whether the user is authorized to make specific change. Not disabling the whole use of roles parameter and disqualifying everybody who uses it for legitimate purposes...

This wouldn't make any difference - the legitimate purpose you are using it for is a workaround for user groups. We've been aware of this for a while, but decided to leave it until later to actually remove.

According to documentation builder and admin parameters are also available only for Business/Enterprise licenses:
Correct - these are also ways to get around groups, by giving someone temporary admin/builder access.

As you mentioned, on self host the previous versions of budibase will still have this feature for free. You can of course remain on that version if you would prefer to continue to use this feature for free, but missing out on future updates of the platform.

[marian001]

Hi @shogunpurple

in our case, we want to let new users register without our involvement, so we want to avoid processing user requests for registration and then inviting them and assigning roles manually. That wouldn't make a good first impression...

You have already implemented a condition into how the API call for user updates works - i.e. it only works for Business/Enterprise users. You should be able to replace that condition with another one, e.g. something like this would help our specific case:

if role = BASIC
proceed with execution
else if license = Business or Enterprise
proceed with execution
else
return error "..only available to Business/Enterprise users"
end if

I'm not a proper developer, so maybe I'm missing something, but I think something like this shouldn't be too difficult to implement to leave some window open for legitimate use.

I would prefer not to take path of giving up on future updates, because at some point this may become a dead end for the whole application.

I'm happy to resolve this some other way, but I didn't find one yet. I tried using Automation and found out you can't create a row in Users table - I got this: "response": "Cannot create new user entry." Is this a feature or a bug? Can you suggest any other way for maintaining Users table programmatically?

[shogunpurple]

@marian001

That would explain it - budibase is generally built for internal tools. SaaS type self sign ups are not generally a good use case. The solution you suggested there just allows the BASIC role (the most common) to be assigned through the API, which circumvents user groups. For clarity - your reference to "legitimate" use is still a workaround to one of our paid features. User groups were created to solve the problem you describe. As noted you cannot workaround this by creating new users from automations either.

I would prefer not to take path of giving up on future updates, because at some point this may become a dead end for the whole application.
I'm happy to resolve this some other way, but I didn't find one yet.

Of course, receiving all future feature and security updates along with community support for free would be ideal. However the "resolution" in your particular case is to either remain on an older version of budibase, fork (or use some modifications/hacks from the community), or if you want to make use of budibases paid features, continue to receive updates, support and more - then the solution is to upgrade to a paid budibase plan.

[Kakovisk]

I am facing the same situation. When I create a user, even with the BASIC role, I get the message: 'message': 'Roles/admin/builder can only be set on business/enterprise licenses - input ignored.'

I created an enterprise application in free mode where some users have the permission to create users for their own department, and it doesn’t make sense to open the Budibase platform for this.