Registration API about registration HOT 3 CLOSED

All endpoints the client interacts with have to be OCS endpoints.
But that is easy too, see https://github.com/nextcloud/notifications/blob/master/lib/Controller/EndpointController.php#L36 for example code

from registration.

Would it make sense to reconsider the flow?

I do agree that admin approval might be important. But the greater goal for me would be to have a signup flow a la dropbox:

So this would be the API:

POST /.well-known/nextcloud/registration

• name
• email
• username
• password

And then as a provider, I could redirect it to another backend like:
https://github.com/jedireza/aqua/blob/master/server/api/signup.js#L33-L36
(If I want ldap signup for instance)

And then in term of flow, we could still do the following a posteriori:

• require email verification yes/no
• require admin approval
• require email domain name
• require payment

And depending on these options, the server could return a response showed to the client.

• "Waiting email confirmation"
• "Waiting admin approval"
• 403 - "You email is not authorized"
• 402 - "Please pay here to proceed"

I know it would require some changes to the current app. But in term of UX, this would be optimal IMHO.

from registration.

I'll be working on implementing a provider list and optional registration feature on the Nextcloud client during this years google summer of code, so I'm willing to implement such an API and especially use the existing registration app for that. @pellaeon Would you be open to pull requests for that?

@pierreozoux That draft makes sense, especially auto discovery via .well-known path would be nice.

I've summarized both of your ideas to this rough API draft:

POST /apps/registration/api/1.0/register/verify

Request Data:

{
	username: 'username',
	displayname: '',
	email: 'email',
}

Responses:

	200 Success
        400 Request invalid (e.g. email/username already exists, invalid email)

POST /apps/registration/api/1.0/register/create

Request Data:

{
	username: 'username',
	displayname: '',
	email: 'email',
	password: '',
}

Response Data

200 Signup successfull

{
	status: 'REQUIRE_EMAIL_CONFIRM',
	statusMessage: 'Please confirm your email adress',
	registrationToken': 'tokenToIdentifyRegistration',
}

GET /apps/registration/api/1.0/register/status/:registrationToken

Response Data

200 if registration status is FINISHED

{
	status: 'FINISHED',
	appPassword': 'unique-app-password',
}

403 if email confirmation is still required

{
	status: 'REQUIRE_EMAIL_CONFIRM',
	message: 'Please confirm your email adress'
}

As an initial starting point i would add two possible states to the registration status:

• REQUIRE_EMAIL_CONFIRM
• FINISHED
  Those can of course be extended when admin approval or payment status features will be included in the app.

Overview of the client procedure:

• User wants to register
• User enters email, username, displayname
• Client checks against /verify
• User enters password
• Client sends request to /create
• Client checks if status is finished
• Client can setup an account using the submitted app password

cc @rullzer

from registration.