Change Add User API

[plusone-nick]

@MooCloud_Matt my Cloudron api token is not exposed to the front-end it is server side and is not passed when invoked.
Edit- Maybe I should have stated it as: my form calls and passes post data to my api and then my api handles the data and calls the cloudron api.

    "name": "set_cloudron_reg_url",
    "module": "core",
    "action": "setvalue",
    "options": {
      "value": "{{$_ENV.cloudron_api_url}}users{{$_ENV.cloudron_api_token}}",
      "key": "test_global"

you're more than welcome to look at the code here: https://git.plusone.network/nick/cloudron-registration-community/-/blob/master/dmxConnect/api/new_user_flow.php

[plusone-nick]

@nebulon
Here is my workflow: There are only two API calls and three set vars.
ENV_vars are NOT hardcoded or passed client side.

• SET - Dynamically generate a Cloudron URL including TOKEN to add a new user
• API - Cloudron api call that includes JSON data from the form input (not including the password field on purpose)

On success of add user:

• SET - Capture user ID to send an invite link
• SET - a dynamic URL which will be used to send the newly created user an Invite email. Use the userid_for_group var
• API - Send the new user an invite email using the dynamic URL (api1_user_id) var & the ($_POST.email) var

Is this wrong? or im missing something....?

IMO the issue resides in the Add User API schema

EDIT - Ideal solution seems to be removing the password field from the add user API schema thus requiring the user to set the password via the invite email and since its originally not required I am assuming it would not negatively impact Cloudron's core code....but you'd have to verify that

Lastly, I am still testing the active/set random password workaround

[plusone-nick]

Update: Random password solution appears to work....
Thanks @michaelpope +1 for the suggestion

• setting the new user to inactive ended up being a labyrinth that I am not trying to entertain

---

TLDR:

The "CATCH 22" is: Without setting a RANDOM password call AFTER a newly created user will result in an attack vector via the add user API - In practice: the "password" field can be injected in the body, passing the form.

Testing further

[MooCloud_Matt]

@plusone-nick
I didn't check the part of our code that manage user creation for ages, but 99% sure, that you don't need to provide a password, or not even a username just an email.

Then you create the invite link with a second request if you want to have the onboarding process managed by cloudron.

Personal note:
Remember that as the server owner you are responsible for the content hosted in it, for this is normally a good idea to have some manual approval before creating an account from a form; or you have to provide a good moderation.