New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Registration API #41

Closed
pellaeon opened this Issue Jun 27, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@pellaeon
Owner

pellaeon commented Jun 27, 2016

nextcloud/server#211 suggests that there could be a RESTful API for the clients to directly register in the client.

API flow that I can think of now:

  1. POST email address to /api/register, returns if address is valid/allowed
  2. token sent to user email, user inputs it to client, client POST to /api/verify, returns correct/incorrect
  3. client show input fields, user input desired credentials, POST credentials and token to /api/create, returns success/failure
  4. client logs user in

A different API design is required considering admin approval #2

Notes:

  • API should be rate-limited to avoid abuse

@pellaeon pellaeon added this to the future milestone Jun 27, 2016

@pierreozoux

This comment has been minimized.

Show comment
Hide comment
@pierreozoux

pierreozoux Feb 25, 2017

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.

pierreozoux commented Feb 25, 2017

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.

@juliushaertl

This comment has been minimized.

Show comment
Hide comment
@juliushaertl

juliushaertl May 24, 2017

Contributor

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

Contributor

juliushaertl commented May 24, 2017

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

@nickvergessen

This comment has been minimized.

Show comment
Hide comment
@nickvergessen

nickvergessen May 31, 2017

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

nickvergessen commented May 31, 2017

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

@juliushaertl juliushaertl referenced this issue Jun 27, 2017

Merged

Registration API #77

3 of 3 tasks complete

@pellaeon pellaeon closed this Sep 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment