Open benel opened 9 years ago
@adeprez I will assign you to this feature as soon as you have joined the team.
I find your list quite exhaustive, I would probably not reach that many alternatives.
Some comments :
_users
database, it is still password stored probably in clear text).For me both A and B can be done by the proxy, so the whole password reset would be a "module" of AAAforRest. And we can avoid to store admin's credentials if we use the proxyauth (i.e. admin authenticated by proxyauth while storing UUID or new password).
Note that storing the password is a bit more complex for couchdb v1.0 and below (including cloudant) : it needs to be hashed client side. I suggest to specifically declare the incompatibility.
@adeprez For A4 and B2, I've just tested if admin edits could be done from an _update
function added to the _users
database. But "Only admins can access design document actions for system databases".
So the only way to do edits with admin privileges will be from a node service that knows admin user credentials:
I just realized that to allow admin access through proxy authentication, it is required to use the X-Auth-CouchDB-Roles
header (whatever the username) :
$ curl -H "X-Auth-CouchDB-UserName: admin" http://127.0.0.1:5984/_active_tasks
{"error":"unauthorized","reason":"You are not a server admin."}
$ curl -H "X-Auth-CouchDB-UserName: whatever" -H "X-Auth-CouchDB-Roles: _admin" http://127.0.0.1:5984/_active_tasks
[]
I just realized that to allow admin access through proxy authentication, it is required to use the X-Auth-CouchDB-Roles header (whatever the username) :
Indeed. That's why I used a different URI in my test 98fc4869ffe3e3b2395863d2e77f7fffc30cde3e.
For your information, I am refactoring the registration feature (from CouchDB attachments to Node static server) so that integration will be easier with node services needed for this part.
I just realized that to allow admin access through proxy authentication
Please note, that the client will not initiate admin requests. Only the reset services.
Please note, that the client will not initiate admin requests. Only the reset services.
Yes I know, but it is a way to allow the reset services to authenticate wihthout having the actual credentials in some config file.
We have designed some mockups to show how the authentication system will work. This system will be used on TraduXio and that's why we use it as demonstrator.
First of all the user who wants to connect needs to open the login page.
We consider now that he tries to connect and fails. He has definitely forgot his password and needs to recover it. To do that he has to click on the link Mot de passe oublié ? (Forgot password? in english). As a result a formular appears on a new page and he just has to fill the field "Email" and clicks on the button.
Then he receives a mail with a link to access to the reset formular. In this last page the user can choose a new one he will never forget (until the next reset).
To have the same mockups style as the register's one (https://github.com/Hypertopic/AAAforREST/issues/28) we made three new mockups with the same information as the ones above.
We can now consider the mockups as finished. However we don't know if the recipe tests are necessary for this functionality. They could be difficult to write because of the external mail. For this particular reason we can imagine a test in two parts.
@franck-eyraud I've seen that you implemented this feature in TraduXio. Great job!
Two questions:
Hi @benel!
I have to say that I wasn't aware of this description while developing that part in TraduXio.
The solution is currently more simple (maybe too simple and that could have security issue). In fact, the password is reset with a generated one by admin, like in B2, but the password is sent by email (the email being previously confirmed - using the A2 solution). So this is the way the unforgeable information is sent to the user. It is quite possible to adapt it to another of the above listed solution.
For your second question, yes it should be possible to reuse it in other software, or external service, at least I thought of it while writing it. It relies on a service which accesses the users database as admin.
The solution is currently more simple
No problem. It can be enhanced later.
the password is sent by email
OK. And I suppose it is the same for account creation, right ?
it should be possible to reuse it in other software, or external service, at least I thought of it while writing it. It relies on a service which accesses the users database as admin.
I suppose there is one Web service and one poller to send e-mails, aren't they? Is the first piece of software implemented with Express.js? Is the second one using follow
library?
OK. And I suppose it is the same for account creation, right ? No, the account is directly created in couchdb _users database, with password set by the user.
I suppose there is one Web service and one poller to send e-mails, aren't they? No, I avoided the web service by creating a "password reset request" doc in couchdb database. The poller catches it, sets the password, and send the email. It also monitors account creation, and validate the email address. But if a web service is already existing, it is probably better to use it.
Is the second one using follow library? Yes. Or to be more precise, it uses the
couchdb-nano
library, which encloses thefollow
one.
No, the account is directly created in couchdb _users database, with password set by the user.
I've just tested account creation. When I read your answer, I didn't get that e-mail address is first "not confirmed" (but usable) then "confirmed" (after clicking on the received e-mail). It's nice.
Out of scope of v2. Could be implemented in Porphyry and LaSuli (maybe through a reusable React component).
The general idea is to send an e-mail with a URI that cannot be forged.
A. Different options could be used in the URI to make it unforgeable:
B. On CouchDB's side, the password can be reset either:
For implementation simplicity (balanced with security), I would favor solution A.4+B.2. @franck-eyraud Do you think about other solutions or do you favor another one?