incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Caprari <matteo.capr...@gmail.com>
Subject Re: Initial couchdb accounts feedback
Date Sun, 10 Jan 2010 16:52:07 GMT
Email addreses are bits of personal information and should be asked
and stored only when they are useful. Corporate apps often require a
registration but not an email.

Couchdb apps should 'usually work' when there's no internet connection.

-teo
On Sun, Jan 10, 2010 at 6:56 AM, Chris Anderson <jchris@apache.org> wrote:
> On Sat, Jan 9, 2010 at 2:17 PM, Brian Candler <B.Candler@pobox.com> wrote:
>> On Sat, Jan 09, 2010 at 10:41:52AM -0800, Chris Anderson wrote:
>>> > Can't quite decide how useful a single "users" database is. I imagine a
user
>>> > would typically be expected to register with each couchapp?
>>>
>>> The plan is that the user is logged into the node, not the db, so that
>>> CouchApp authors can just take for granted that the user is or isn't
>>> logged in, and never have to write any session management code
>>> themselves. If you are jchris when you use the calendar it make sense
>>> that you'd be jchris when you write a blog entry.
>>
>> However it's also possible that non-cooperating applications exist on the
>> same server.  In the limit, each database on a server could belong to a
>> different customer, and none of them trust each other. I wouldn't want to
>> have to run a separate couchdb server instance on a separate port for each
>> one.
>>
>> So given a single users database, then to make this work I think this
>> implies the following.
>>
>> 1. The usernames must be guaranteed *globally* unique - i.e. E-mail
>> addresses. Otherwise, app1's "bob" might be different to app2's "bob".
>>
>> 2. When you create a new account, the ownership of that handle must be
>> authenticated, by sending out an E-mail with an activation link.  (Looking
>> at the screencast, it seems that anyone can claim any username on a
>> first-come, first-served basis at the moment)
>>
>> 3. The 'roles' are really to do with authorization, not authentication. I
>> think that these belong with the databases themselves, not the users file.
>> For example, I think the prescription application should track of which
>> usernames have the 'doctor' role, not the users database.
>>
>> Consider also that setting roles is an application function, not a server
>> administrator function. For example, the health services manager might want
>> to be able to assign the 'doctor' role to certain individuals, without
>> having to get the server administrator involved.
>>
>> If the roles were a document or documents in the app database, this is easy
>> (validate_doc_update can know which role(s) are permitted to change the
>> role(s) of other users)
>>
>> Some consequences
>> -----------------
>>
>> On the plus side:
>>
>> * If the usernames were validated E-mail addresses, then I agree that having
>> a single users database is a bonus. That is, once signed up once, you are
>> ready to authenticate to any app on that server, and can switch between them
>> at will.
>
> I would *love* to see an easy email loop that CouchApps can access.
>
> I bet the Raindrop project has exactly the code you'd need to
> implement this as a CouchApp + external.
>
> I'm not sure about adding this complexity. What if the user is
> experiencing a network partition from their email provider? They
> should still be able to sign up.
>
>>
>> * If usernames were E-mail addresses, then most app writers will want to
>> have them validated, so building the activation-link logic into couchdb
>> will save them work. (However, each app might want to provide its own
>> E-mail template, so that the first signup is suitably "branded")
>>
>> * Keeping authentication separate from authorization, and in particular
>> storing roles within each database, would work well with OpenID which only
>> provides authentication.  That is, with OpenID we know *who* you are, but
>> still need to store locally *what* you can do.
>>
>> * Authorisations (role membership) could replicate with the application
>> itself
>>
>> On the minus side:
>>
>> * some schemes like LDAP *might* want to combine authentication and
>> authorization in the same database
>>
>> * if we kept the authorization centralised it means that, in principle, a
>> user could login and immediately see all the apps that they have access to.
>> That is, you could have roles per app but keep them in the users database:
>> e.g.
>>
>>    "username": "fred@example.com",
>>    "roles": {
>>        "prescriptions":['doctor'],
>>        "fredsblog":['blogadmin']
>>    }
>>
>> Futon can immediately guide the user to the apps which they have access to
>> (although there might also be public apps that can use).  But it makes it
>> hard to replicate the roles.
>>
>> * There is a middle ground, which is what I've actually implemented in my
>> own multi-database app: have a global users database which also contains one
>> authorization document per app database (mapping users to roles for that
>> db).  This means that I can still use a view to determine all databases a
>> user has access to when they login; and when I delete a database, I only
>> need to delete one document from the global database as well to get rid of
>> the related authorizations.
>>
>> I would have preferred to have the authorizations within each db, but this
>> wouldn't let me present the user with a list of the databases they can
>> access, without extracting this periodically.
>>
>> Regards,
>>
>> Brian.
>>
>> P.S. I'm not sure how the authentication code plugs in at the
>> moment.  Perhaps there could be an auth module which runs an external
>> process and talks to it over a socket, like a view server?  Then it would be
>> easy to implement things like sending out validation E-mails without having
>> to write it in Erlang.
>>
>> P.P.S. One other thought: when it is possible to restrict read access per
>> database, it would be nice to distinguish "not authorized" from "any
>> authorized user" - perhaps with a hardcode role which all authorized users
>> gain.
>>
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>



-- 
:Matteo Caprari
matteo.caprari@gmail.com

Mime
View raw message