Disable account confirm emails when creating users via API

It should be fine, we only whitelist staged, approved and active. Admin/moderator is not in the whitelist

5 Likes

I am still having issues creating user accounts using the API. Here are the params I am passing to create the user

$params = array(
            'name'                  => $user_details['name'],
            'username'              => $user_details['username'],
            'email'                 => $user_details['email'],
            'password'              => $user_details['password'],
            'challenge'             => $api_keys->challenge,
            'password_confirmation' => $api_keys->value,
            'active' => 'true',
            'approved' => 'true',
            );

The user is being successfully create and no email is being sent. But when I try to login using the account created I am getting the following error message.
You can’t log in yet. We previously sent an activation email to you at *@.org. Please follow the instructions in that email to activate your account. Do I have to change any other settings on the admin? Any help is appreciated.

You might try activating the user with a second API call.

@pfaffman The issue that I am facing with that approach is, a confirmation email gets sent out when I create the user without the “active” parameter. Ideally I would want to create and activate an user using the api without sending the confirmation email.

So my idea was to create the user that way and then try to activate the user via a second API call.

Usually the answer to questions like this are to use SSO, but it’s not clear that it’s what you should do.

Unfortunately we cant use SSO.
The issue with creating an user by passing the active flag and then trying to activate is that we cant activate an already activated user.
I was hoping when active =“true” is passed as a parameter to create the user the user account should be created and activated without sending the confirmation email. Looks like the API request is not doing that.

1 Like

That sounds like a bug to me.

My next suggestion would be to create it with active. Then deactivate and reactivate with the API. (Or to submit a PR that fixes the bug.)

Yes, Looks like this is the only method that works. Thanks.

1 Like

Is this working at all?

deactivation and activation also seems not to work properly. I see emails still being sent to pre activated users.

I tried sending API calls setting active=true and approved=true , but get the following response:

{
“success”: true,
“active”: false,
“message”: “You’re almost done! We sent an activation mail to ‘[my email]’. Please follow the instructions in the mail to activate your account.If it doesn’t arrive, check your spam folder.”
}

However, no e-mail is sent and no user seems to be created - at least, I don’t see any in the admin interface. What could be the reason for that?

They might be under the “new” tab instead of the “active” tab?

I’m not exactly sure what your use case is for creating users for the API but I would consider looking into using Single Sign on.

However, these are the current steps you need to perform in order to create a user via the API without sending a confirmation email. You will have to make 3 requests:

  1. Create the user with the active=true param
  2. Deactive the user
  3. Activate the user.

Hi Blake, thank you for your response!

No, unfortunately not. I checked that. For some reason, I have the same list of users in the “Active” and “New” tabs, just in a different order.

I am going to migrate from another place (YouTrack, an issue tracker), and would like to make it as smooth and seamless to our users as possible. So my plan was to move all users via API, then move their posts (pull that from the issue tracker and create them in Discourse via API), comments and attachments, and after that send invitations. This is why I need to create users first - to make them the authors of their posts and comments.

Yes, I’ve read that in this topic above. The problem is that for step 2 I need to know the user ID, which is supposed to be in the response to step 1, but it isn’t. Also, the response message to “active=true” should be different, as shown here: Creating Active Users via the API gem

If the user was actually created the user_id will be in the response. But considering you can’t find the user in the admin dashboard they probably weren’t created for some reason.

Ah okay, so you are creating an importer. You do not want to do this though API calls, but you want to create an importer script and run it directly from inside of your docker container.

I would look at one of the many examples listed in discourse/script/import_scripts at master · discourse/discourse · GitHub

May I ask why?
(I have admin access to Discourse, but not to the server/docker container, so I would have to ask someone else to do that.)

Seems so! Are there any known causes for that? Something in the settings?

It is 100x faster if it is a large import and you get direct access to the the ImportScripts::Base class methods that make is super easy to create users and many other things for imports like creating groups, categories, topics and posts:

You could create the script and have them run it if need be.

No known issues around this. Here is an example curl request to create a user:

curl -i -sS -X POST "http://localhost:3000/users" \
-H "Content-Type: multipart/form-data;" \
-H "Api-Key: ****" \
-H "Api-Username: system" \
-F "name=cfbcc77ae9f4230d2c25" \
-F "username=cfbcc77ae9f4230d2c25" \
-F "email=cfbcc77ae9f4230d2c25@example.com" \
-F "password=3f348653105f05505f5f1a3ff70ef984" \
-F "active=true" \
-F "user_fields[1]=cfbcc77ae9f4230d2c25" \
-F "user_fields[2]=828c0ec3a76"

which returns:

{"success":true,"active":false,"message":"\u003cp\u003eYou’re almost done! We sent an activation mail to \u003cb\u003ecfbcc77ae9f4230d2c25@example.com\u003c/b\u003e. Please follow the instructions in the mail to activate your account.\u003c/p\u003e\u003cp\u003eIf it doesn’t arrive, check your spam folder.\u003c/p\u003e","user_id":4}

It’s possible something has changed because it looks like emails are being sent now, but the user is still being created. Looks like the active=true isn’t being applied.

1 Like

I should also admit that I have no knowledge of Ruby :man_facepalming:

So I will try to investigate the issue with API a bit further. Will try to run a call similar to yours. Just a few things to clarify:
a) The endpoint is [mydomain]/users.json, right?
b) Content-Type should be "multipart/form-data" or "application/json", as written in the API docs?
c) What are "user_fields" for?

1 Like

Yes, usually you want to append .json to all routes. Yes, you can also use application/json for the content-type and the user_fields are optional, it was just part of my example script I already had.

2 Likes

It worked!

Sending exactly the same curl request as yours (with my data) resulted in the creation of an activated user.
Not sure yet, why it didn’t work for me originally when I was sending similar requests from Postman. I will further investigate this issue, and report here if I find anything significant.

Thank you for your help!

2 Likes

This has been resolved with this commit:

5 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.