Closed Bug 1074943 Opened 7 years ago Closed 7 years ago

[buddyup] Add registration API

Categories

(support.mozilla.org :: Users and Groups, task, P2)

Tracking

(Not tracked)

RESOLVED FIXED
2014Q4

People

(Reporter: mythmon, Assigned: mythmon)

References

Details

(Whiteboard: u=user c=api p=3 s=2014.18)

Clients should be able to register users programmatically, providing authentication details to create a new user. In particular this should allow Buddyup to make helpee accounts with no user intervention.

Outstanding questions:

* Can any client do this, or do they need some sort of client token? (Problematic with client side apps).
* Is this rate limited? If so how.
* Do these users require email confirmation?
* Do these users have different permissions than a normal user? What is different about them?
Blocks: bu-server
OS: Linux → All
Priority: -- → P2
Hardware: x86_64 → All
Target Milestone: --- → 2014Q4
This has some unanswered questions, and should be done carefully. I'll make it 3points for that.
Assignee: nobody → mcooper
Whiteboard: u=user c=api p= s=2014.18 → u=user c=api p=3 s=2014.18
The current version of the API in that bug has these answers to the questions above:

* Can any client do this, or do they need some sort of client token? (Problematic with client side apps).

  Any one can make calls to the API to make new users.

* Is this rate limited? If so how.

  This is not rate limited.

* Do these users require email confirmation?

  No. And in fact these users are not required to have emails at all (though they can.)

* Do these users have different permissions than a normal user? What is different about them?

  These users have the same permissions as a user created through the website.


As far as I can tell, kitsune is actually ok with users not have emails, despite my earlier assertions. I made some situations where a user would receive email, and in those cases, there were no errors, and no emails were sent to the non-existent email addresses. I take this as a good sign.
Status: NEW → ASSIGNED
I'm wondering whether this exposes us to more spam than currently possible, but I'm not sure. 
* New user registration is not rate limited right now, IIRC. 

* We do currently expect a working email address, but we don't do any banning based on that.

Mike, what's your take on this? Do you see how this could expose us to more spam in the forums? Any thoughts on mitigation?
This doesn't expose us to spam that wasn't possible before. Email verification isn't a tool to prevent spam on our side, just a way to make sure we don't send unwanted email to people. I should add email verification to this.

It would be pretty straight forward for me, if I were an attacker, to create a bot to register on SUMO, verify an account, and then post spam. It will be easier with the APIs, but there isn't any new attack surfaces, as far as I know.

We can add rate limiting. We'll likely need to do this with the API anyways. We could implement spam detection, which we have been talking about for a long time now. The work on Input this summer didn't result in something we could apply to SUMO. These aren't specific to the API.

I did some tests with a user that didn't have an email address. It seems fine, and the site didn't blow up. I could do more testing if we are worried about it. I made some assumptions about our data models requiring emails earlier, and I think they ended up not being true. I wasn't able to find anywhere in which we (from a code execution point of view) require a user to have an email. Our notification system, django-tidings, is robust to users not having email addresses. They simply don't get notifications, but I didn't see any errors or site breakage.
Ricky just pushed this.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.