Add REST API for creating an account #9572

Gargron · 2018-12-19T06:04:14Z

The method is available to apps with a token obtained via the client credentials grant. It creates a user and account records, as well as an access token for the app that initiated the request. The user is
unconfirmed, and an e-mail is sent as usual.

The method returns the access token, which the app should save for later. The REST API is not available to users with unconfirmed accounts, so the app must be smart to wait for the user to click a
link in their e-mail inbox.

The method is rate-limited by IP to 5 requests per 30 minutes.

Motivation: Multiple app developers have requested this. Currently an end-user cannot just install a mobile app and start using Mastodon, they must visit the website first. This, on the other hand, would allow a fully immersive sign-up process. The mobile app can implement a server picker, etc...

Risks: The API can be used to create spam bots. However, it is just as easy for a dedicated spammer to use the HTML form to create spam bots, and this API method actually has a higher rate limit (5/30 min here vs 25/30 min). E-mail confirmation is still required, so nothing changes there...

Gargron · 2018-12-19T06:04:55Z

app/controllers/api/base_controller.rb

@@ -68,7 +68,7 @@ def current_user
  end

  def require_user!
-    if current_user && !current_user.disabled?
+    if current_user && !current_user.disabled? && current_user.confirmed?


This condition was unneccessary before because unconfirmed users had no way to obtain an access token.

Gargron · 2018-12-19T06:05:29Z

app/controllers/api/v1/accounts_controller.rb

@@ -16,6 +17,16 @@ def show
    render json: @account, serializer: REST::AccountSerializer
  end

+  def create
+    token    = AppSignUpService.new.call(doorkeeper_token.application, account_params)
+    response = Doorkeeper::OAuth::TokenResponse.new(token)


This mirrors the usage of this class by Doorkeeper controllers.

nolanlawson · 2018-12-19T07:30:59Z

This looks great. The only downside I can foresee is that (as you pointed out), the username and password are exposed to the app. But I don't see any way around that.

Having the app show a temporary screen saying "please go click a link in your inbox" is fine, but it's a bit odd that that link will go to the main Mastodon frontend, and there's no way for the app to intercept it or at least be notified that the user is now verified.

Maybe the API could accept a redirect URL as well, and the Mastodon frontend could display some text like, "Thanks for confirming your email. Application FooApp would like you to continue your signup here."

Gargron · 2018-12-19T07:36:44Z

Maybe the API could accept a redirect URL as well, and the Mastodon frontend could display some text like, "Thanks for confirming your email. Application FooApp would like you to continue your signup here."

Hm... So far it was possible to implement this PR without changing data structures or requiring apps to re-register, but I don't think an extra redirect could be made with existing parts... Need to save information that a user was created by an app to be able to do that... Plus add an extra redirect URI to apps... Unless it would be OK to redirect users to the already saved OAuth redirect URI...

nolanlawson · 2018-12-19T07:51:49Z

Hmmm, redirecting to the already saved OAuth URL would probably be fine. The app can just poke the API at verify_credentials to confirm that the user is confirmed, so no other info is required.

Gargron · 2018-12-20T00:53:38Z

Done

mayaeh · 2018-12-20T01:57:14Z

I think that we need to check the rules and terms and the conditions of it instance before creating an account. What do you think?

Also, how about making it possible to switch by setting ON/OFF of this API?

Gargron · 2018-12-20T02:57:27Z

I think that we need to check the rules and terms and the conditions of it instance before creating an account. What do you think?

An app could implement a web view to /about/more. Since rules are HTML, with potentially complex things, images, iframes, you would end up needing to render a web page anyway.

Also, how about making it possible to switch by setting ON/OFF of this API?

Maybe. Apps must already deal with this API missing from older versions, so there is no consistency to lose.

mayaeh · 2018-12-20T06:02:11Z

An app could implement a web view to /about/more. Since rules are HTML, with potentially complex things, images, iframes, you would end up needing to render a web page anyway.

Fediverse have also instances for specific topics.
It is unfortunate that a mismatch occurs that "I created an account from an application, but it was not a place to accept me".

I think that it is heavy to let app developers handle all the measures to prevent them.

This is one idea:

When requesting creation of an account with this API, the server first returns a link (/about etc.) and a unique ID.
Then, the account registration is accepted only within a certain period after receiving the flag of "agree" and its ID with this API.

(I think that it is necessary to delete the registration unique ID expired periodically by cron job etc.)

I think it is in vain to send it link (/about, etc.) because it is already known.
But I hope they will read it before registering.

mayaeh · 2018-12-20T07:35:21Z

Maybe. Apps must already deal with this API missing from older versions, so there is no consistency to lose.

Several servers seem to be adding reCAPTCHA to account registration of WebUI.
If we merge this API in this state, I think that the effect of reCAPTCHA will be lost.
Several server administrators are afraid that this will again increase spam accounts.

Therefore, it seems that they want an option to disable this API.

(I do not introduce reCAPTCHA, because that is difficult for me to break through.)

The method is available to apps with a token obtained via the client credentials grant. It creates a user and account records, as well as an access token for the app that initiated the request. The user is unconfirmed, and an e-mail is sent as usual. The method returns the access token, which the app should save for later. The REST API is not available to users with unconfirmed accounts, so the app must be smart to wait for the user to click a link in their e-mail inbox. The method is rate-limited by IP to 5 requests per 30 minutes.

…h an app

Gargron · 2018-12-23T19:54:54Z

When requesting creation of an account with this API, the server first returns a link (/about etc.) and a unique ID.

There is no guarantee that an app will show anything to the user, it could just send the ID back straight away. Likewise, even without the ID an app could make the user read through that page and click "Agree"

Also, how about making it possible to switch by setting ON/OFF of this API?

I have been thinking about the on/off switch for this feature, and I think the admin settings UI has become too complex. Everything is in one form, that doesn't work well. I wouldn't want to add one more checkbox to it. :(

Neustrashimy · 2018-12-24T01:56:45Z

Could you implement Boolean "confirmed to terms" parameter for creation API?
I want to get confirm that new user has read my instance's custom terms/rules and agreed.
thanks.

mayaeh · 2018-12-24T01:59:42Z

There is no guarantee that an app will show anything to the user, it could just send the ID back straight away. Likewise, even without the ID an app could make the user read through that page and click "Agree"

I agree with that.
Besides, current flow of account creation API is consistent with WebUI.

However, WebUI has the following notation:
By clicking "Sign up" below you agree to follow the rules of the instance and our terms of service.

I think that if there is no equivalent to this API, if a registered user causes trouble, it will be considered "This response is unjust because you are not showing such a document".

I think that this complaint will be directed to the instance administrator, not to the application developer.

I have been thinking about the on/off switch for this feature, and I think the admin settings UI has become too complex. Everything is in one form, that doesn't work well. I wouldn't want to add one more checkbox to it. :(

I think that there are really many items...

Gargron · 2018-12-24T03:12:50Z

Okay, I have added required agreement param to the API.

mayaeh · 2018-12-24T03:28:07Z

Thank you for considering!

Neustrashimy · 2018-12-24T03:36:34Z

thanks a lot!

mayaeh · 2018-12-24T17:41:06Z

I confirmed that I can create an account using this API.
There is no error as far as I can see.

I think that it is necessary to carefully write a document, such as handling "agreement" flag later.

* Add REST API for creating an account The method is available to apps with a token obtained via the client credentials grant. It creates a user and account records, as well as an access token for the app that initiated the request. The user is unconfirmed, and an e-mail is sent as usual. The method returns the access token, which the app should save for later. The REST API is not available to users with unconfirmed accounts, so the app must be smart to wait for the user to click a link in their e-mail inbox. The method is rate-limited by IP to 5 requests per 30 minutes. * Redirect users back to app from confirmation if they were created with an app * Add tests * Return 403 on the method if registrations are not open * Require agreement param to be true in the API when creating an account

Gargron added the api REST API, Streaming API, Web Push API label Dec 19, 2018

Gargron commented Dec 19, 2018

View reviewed changes

Gargron force-pushed the feature-app-sign-up branch from 8245896 to 322869a Compare December 20, 2018 00:32

Gargron added 4 commits December 22, 2018 20:20

Redirect users back to app from confirmation if they were created wit…

00b8a4b

…h an app

Add tests

541479d

Return 403 on the method if registrations are not open

232e3dc

Gargron force-pushed the feature-app-sign-up branch from ddb6e5a to 232e3dc Compare December 22, 2018 19:21

Gargron force-pushed the feature-app-sign-up branch from b88d7d3 to 2c09d30 Compare December 24, 2018 03:11

Gargron force-pushed the feature-app-sign-up branch from 2c09d30 to fa5f165 Compare December 24, 2018 16:26

Require agreement param to be true in the API when creating an account

2bf7bb5

Gargron force-pushed the feature-app-sign-up branch from fa5f165 to 2bf7bb5 Compare December 24, 2018 16:38

mayaeh approved these changes Dec 24, 2018

View reviewed changes

Gargron merged commit 5d2fc6d into master Dec 24, 2018

Gargron deleted the feature-app-sign-up branch December 24, 2018 18:12

mayaeh mentioned this pull request Dec 26, 2018

Not localized when creating account from the account creation API #9627

Closed

neet mentioned this pull request Jan 20, 2019

WIP: Support Mastodon 2.7.0 neet/masto.js#36

Merged

1 task

moritzheiber mentioned this pull request Jan 23, 2019

SSO account creation fails with "Agreement must be accepted" #9906

Closed

ClearlyClaire mentioned this pull request Feb 13, 2020

Fix sign-ups without checked user agreement being accepted through the web form #13088

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add REST API for creating an account #9572

Add REST API for creating an account #9572

Gargron commented Dec 19, 2018 •

edited

Loading

Gargron Dec 19, 2018

Gargron Dec 19, 2018

nolanlawson commented Dec 19, 2018

Gargron commented Dec 19, 2018

nolanlawson commented Dec 19, 2018

Gargron commented Dec 20, 2018

mayaeh commented Dec 20, 2018

Gargron commented Dec 20, 2018

mayaeh commented Dec 20, 2018

mayaeh commented Dec 20, 2018

Gargron commented Dec 23, 2018

Neustrashimy commented Dec 24, 2018

mayaeh commented Dec 24, 2018

Gargron commented Dec 24, 2018

mayaeh commented Dec 24, 2018

Neustrashimy commented Dec 24, 2018

mayaeh commented Dec 24, 2018

Add REST API for creating an account #9572

Add REST API for creating an account #9572

Conversation

Gargron commented Dec 19, 2018 • edited Loading

Gargron Dec 19, 2018

Choose a reason for hiding this comment

Gargron Dec 19, 2018

Choose a reason for hiding this comment

nolanlawson commented Dec 19, 2018

Gargron commented Dec 19, 2018

nolanlawson commented Dec 19, 2018

Gargron commented Dec 20, 2018

mayaeh commented Dec 20, 2018

Gargron commented Dec 20, 2018

mayaeh commented Dec 20, 2018

mayaeh commented Dec 20, 2018

Gargron commented Dec 23, 2018

Neustrashimy commented Dec 24, 2018

mayaeh commented Dec 24, 2018

Gargron commented Dec 24, 2018

mayaeh commented Dec 24, 2018

Neustrashimy commented Dec 24, 2018

mayaeh commented Dec 24, 2018

Gargron commented Dec 19, 2018 •

edited

Loading