couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Initial couchdb accounts feedback
Date Sat, 09 Jan 2010 18:41:52 GMT
On Sat, Jan 9, 2010 at 7:34 AM, Matt Goodall <> wrote:
> Hi,
> Just a quick bit of feedback after an initial play with the new accounts
> stuff. Definitely looks interesting! This is based on a fresh install from
> trunk (r896989).
> Oh, I should point out that I've never used couchdb to host any sort of
> couchapp yet (I use couchdb as a "conventional" store) so I may well be
> missing the point in a few places.

Thanks for the feedback. It's much appreciated.

> = Bugs =
> If the 'users' database doesn't exist then the doc for the first admin user
> (the one who spoils the party) does not get created.

Good catch - I thought this was intermittent and was gonna be a pain
to fix, but if it's easy to trigger it'll be easy to fix.

> Anyone can delete users' docs (even an admin user's doc). _admin users
> should be able to delete docs. Unauthenticated users should not. I can't
> decide if a user should be able to delete their own doc.

Agreed. This is a simple bug that's fixed on my laptop. Once I add a
test I'll check it in. For now I'll let users delete their own docs.

> = Possible Simple Changes =
> Perhaps the database could be renamed to "_users" as it's a couchdb-managed
> database? I imagine it's reasonably likely there are databases called
> "users" in use already.

Worth looking into. I wanted to avoid using an underscore name, but
maybe this isn't practical. What do others think?

> The _admin/users view emits the whole doc. Would it make sense to use
> include_docs=true where necessary and save the map's emitted value for
> something useful in the future?

That view is left over from earlier code so I'll just delete it altogether.

> Perhaps store admin users in the "users" database with a role of "_admin",
> and leave local.ini alone? I guess there are some
> backward-compatibility issues to resolve here.

Keeping them in the config is better. They are more robust there
(loaded before any db is loaded, not deleted if the db file is
deleted, etc) also I like it that the admin passwords aren't in the
users db, it should be more secure that way.

There is a validation that system roles (like _admin) can never be
stored in the users db. They are always applied by CouchDB based on
other factors.

> = Other Thoughts =
> Is the "users" database designed to be replicated?

Yes. But replicated can mean different things depending on the use-case.

> If so, isn't there a real
> danger of getting a username conflict and exposing another user's personal
> data in a couchapp?

I think this danger isn't so bad. The main reason is that read-control
(planned but not yet implemented) will be per-database. So if a user
can read data from the database as themselves, they don't get special
read access by logging in as different user.

However, if you have a private db (only jchris can read it) then if a
user on another node is named jchris, and the 2 nodes are merged,
there's a problem deciding can read the db.

There's things we can do to prevent username hijacking -- probably the
most important thing would be to check for conflicts on login, and
prevent people from logging in if the user doc is in a conflict state.
This would have to be resolved by an administrator.

Beyond being wary of conflicts, I think the current validation
function will prevent non-admins from introducing conflicts on user
documents. If you can't update the document, you can't write a
conflicting version of it. However, an admin could inadvertently
introduce conflicts if eg: there was a jchris in accounting and a
jchris in marketing and the 2 users-dbs were merged.

> Perhaps each user needs a uuid of some sort for
> couchapps to reference (instead of using the username) so the conflict
> winner still only gets to see their own data.

The problem is we want the login token to be both memorable and
unique. I think the best solution is to encourage people to use email
addresses as login tokens. Maybe the Futon UI + validation function
should go further toward requiring that. (I'm not that into the idea
of enforcing the presence of an @ sign in your username, but maybe
it's worth it...)

> 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.

> A user can edit their own doc so I assume that means the design is to allow
> for extra information in the docs, e.g. the user's real name, email address,
> etc?

We should discourage app devs from overloading the users documents.
Instead they should use the user-id to create a document in the app
db, with user preferences.

I'm not sure if it's a good idea to attempt to enforce these
constraints in code. Hopefully a few examples of doing it right should
be enough to get people pointed in the right direction.

> Having that information in a different database to where the user's
> actual data is stored seems quite limiting, e.g. for view collation to see
> the user's name and postings. The solution is probably per-database users.

I don't think we want per-database users. Because you only want to
login / logout of the server. I think we should encourage applications
to maintain user profiles in their own databases, keyed off the user

Because all the apps on the node share the same session, you can do
cool stuff like have a user-profile couchapp, which just handles your
nickname and avatar icon. Other apps could then use those resources
when displaying user info.

Probably the closest thing to this setup that people are familiar with
is Google App Engine. As an app developer, you just get the user info
from a provided API. Of course we add the notion that apps running on
the same node can query each others' databases.

> openid support would be cute. :)

We've got oauth support. OpenId would definitely be nice. It'd also
help with the unique identifiers thing.

> Hope that all makes sense.
> - Matt

Thanks again for the feedback,

Chris Anderson

View raw message