Skip to content
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

pellaeon opened this issue Jun 27, 2016 · 3 comments

Registration API #41

pellaeon opened this issue Jun 27, 2016 · 3 comments


Copy link

@pellaeon 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


  • API should be rate-limited to avoid abuse
@pellaeon pellaeon added this to the future milestone Jun 27, 2016
Copy link

@pierreozoux 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:
(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.

Copy link

@juliushaertl 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',


	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

	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

	message: 'Please confirm your email adress'

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

    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

Copy link

@nickvergessen nickvergessen commented May 31, 2017

All endpoints the client interacts with have to be OCS endpoints.
But that is easy too, see for example code

@juliushaertl juliushaertl mentioned this issue Jun 27, 2017
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
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.