Calling Discourse API to add multiple users fails on the second user


(Bill Graziano) #1

I’m working on a little c# utility to move users from an existing forum into Discourse. I have the code working to add a single user. However when I call the code a second time I get an error that “Signup is not allowed from this account.”.

Apparently after you call the API to create a new account, it switches you to that account. I’ve tried starting the API calls over at the beginning. I’ve tried keeping the same forum session from my first call when I was logged in as the admin user. Here’s my workflow:

  1. Call the forum general URL once with the api_key and api_username and save the cookie I get back.
  2. For each user I’m trying to add:
    (a) GET /users/hp.json and save the two values returned
    (b) GET /session/csrf.json and save the value returned
    © POST /users with the assorted values from above.

The first user goes through just fine and I get the confirmation email. The second user fails with “Signup is not allowed from this account.”

I’ve tried reusing the API key and API username in the POST to /users but that didn’t help.

Is what I’m doing even possible?

My best guess is the POSTing to /users resets the _forum_session cookie to the new user and I’m not completely resetting it back to what it should be. Does that sound reasonable?


(Jeff Atwood) #2

Too many trust level 0 users from the same ip. Either bypass the check or increase the allowed value in site settings. If an staff account exists its ip is excluded from this check, so making one of the accounts staff will also fix it.


(Bill Graziano) #3

YAHOOO! Increased the max new accounts per IP address to 100 and it worked fine. Thanks! I can see I need to spend more time going through all the configuration settings.

FYI - The IP I’m using is the only IP I’ve used to access the site and one of the accounts that already existed and is an administrator and was created from that IP. So I’m not completely sure the bit about the staff account excluding an IP from the check is working the way I thought it would from your description.


(Jeff Atwood) #4

That change is from 2 days ago so make sure you are on the very latest version. If it is not working let us know.


(Bill Graziano) #5

Ok, now I’m a little confused. My main account shows as "Admin? true "when I edit my own account from the admin page.

When I go to Groups and look at “admins” and “staff” it does not show up. It does show up in trust_level_0 though.

Zeeet! As I was typing this post, my account now shows up as both an admin and a staff. I swear I didn’t change anything. Color me confused. Plus the groups now show up when I edit my account. Hmmm.

(And replying to your latest post … I just installed this morning using your standard Docker install. Which is SUPER-HANDY! A thousand thank you’s for that!)

Oh well. I’m guessing there’s some stuff running behind the scenes. I’ll let it settle down and test again.


(Greg Kempe) #6

FYI, this is the “max new accounts per registration ip” setting in the Spam section of the Settings area in the admin site.


(Thomas Davids) #7

How would we go about bypassing the check? Is that possible to do through the API?


(Sam Saffron) #8

Its in site settings, a bit confused cause SSO should be causing it to bypass anyway in your case.


#9

I have a (kinda crappy) library that I use for handling external signups (with a questionnaire and etc) – how I solve it is to pass X-Forwarded-For, and use https://gist.github.com/ArkQA/2f0b0a4a3a14b249eba3 in the config.

I don’t use SSO for this, since I don’t actually have an external data source.


(Jeff Atwood) #10

No SSO no longer bypasses those checks, as we get blamed for “spam” that is a result of poorly vetted SSO systems.


(Kane York) #11

That’s a fix for an ‘unconfigured’ proxy in front, not for the issue of lots of real users from the same real IP.