Register as a new user

[benel]

Alexis created a nice user registration form.

Users are created on CouchDB and can be used for authentication on AAAforREST (with HTTP basic or cookie on frontend, and HTTP basic on backend) or even through AAAforREST with cookie forwarding.

In the future, it could be upgraded with e-mail verification, password reset, etc.

As an HTML+jQuery page it can be served either by CouchDB as attachments (as it is for now) or by NodeJS.

However the real point is how this UI and the corresponding API (_users) will be integrated with existing apps:

• as a javascript altering the app UI,
• as an other web app (e.g. http://auth.acme.org/),
• as a special handler available to any app that wants it (e.g. http://app.acme.org/_users) – the registration app would be stored in the users database,
• as the body of the 404 error (choose "cancel" )

Integration	Pros	Cons
jQuery plugin		Need to add a script link on the app.
http://auth.acme.org/		Need to add a link on the app.
http://app.acme.org/_users		Need to add a link on the app.
Error 404 body	App unmodified.	Uncommon user experience.

Of course we could adopt two solutions at the same time (solution 4 and one of the first three) to let the integrator choose between modifying the apps or not.

An objection against solution 2 could be raised if we wanted to automatically authenticate after registration (unless a cookie can be set for every subdomain of the same domain). However, I wonder if it is a good thing as many password manager don't record credentials in such cases.

@franck-eyraud Do you think about any other way to integrate it, any other criterion we should consider, or any comment on mine?

[franck-eyraud]

Very nice registration form, indeed!

I suppose tha the case depends whether the app knows about being use with authentication or not (I think for instance thatCassandre doesn't, right?)
If not, then a solution that does not impact the app seems necessary. But there would also be a need to handle log in, if the cookie is to be used.
It the app does need authentication but wants to delegate the reistration, then it can take a parameter on how to handle registration (and here also a log in form could be a plus)

unless a cookie can be set for every subdomain of the same domain

Yes, this is possible, but could be blocked by some browser. If it is the case, then the user will just have to login again just after that.

However, I wonder if it is a good thing as many password manager don't record credentials in such cases.

If login and registration are on 2 different domains, they will just record credentials twice, and then should work like a charm.

Since the registration will anyway be configured as part of a site, I think we can use the same domain as the app, with the proxy redirecting to a different server if needed.

as the body of the 404 error (choose "cancel" )

Don't you mean 401 or 403 error ?

http://app.acme.org/_users

Just because I realized it recently, I inform you that the common handlers of couchdb work only if the app is accessed through a couchdb virtual host. Using the path of AAAforRest to db/_design/ddoc/_rewrite is insufficient (maybe with nosecure_rewrites and the correspndign rewrite rules this would work.

[benel]

Don't you mean 401 or 403 error ?

Sorry, I was on a train with very low connectivity. I had not even finished the comment in the parenthesis.

[benel]

maybe with no secure_rewrites and the corresponding rewrite rules this would work

Indeed. I tested it yesterday.

[benel]

@adeprez The http://auth.acme.org/ option is available in a6953eb (in a feature branch while the other account-related features are still on development).

[trinhtt]

Registration mockup: