couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <matt.good...@gmail.com>
Subject Initial couchdb accounts feedback
Date Sat, 09 Jan 2010 15:34:51 GMT
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.


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

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.


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

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?

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.


= Other Thoughts =

Is the "users" database designed to be replicated? If so, isn't there a real
danger of getting a username conflict and exposing another user's personal
data in a couchapp? 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.

Can't quite decide how useful a single "users" database is. I imagine a user
would typically be expected to register with each couchapp? If those
couchapps happen to be hosted in the same couchdb then that means that the
user would have to come up with two (or more) usernames, because their
preferred username would already be taken by registering with the first
couchapp. Perhaps the user docs could include some sort of application id
that can be included in the users view (it could even emit username and
application+':'+username rows)?

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

openid support would be cute. :)


Hope that all makes sense.


- Matt

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message