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 Sat, 09 Jan 2010 19:22:55 GMT
Hi.

i think _users is a good choice:
underscore is fairly established as "pretend private" marker, and it's
easy to recognise it
as couchdb-ish because it'used already for _utils, _view, etc. (It
also true that _utils is not a db and users may get confused...)

I'm working on openid authentication handler, but don't hold your breath.

I agree that per-instance-sessions are nice and have cool
implications, but it means that if I want to run
applications that don't share users, I have to fire up two couchdb
instances. This is not a bad thing, just probably not
very convenient with the current init scripts.

-teo

On Sat, Jan 9, 2010 at 6:41 PM, Chris Anderson <jchris@apache.org> wrote:
> On Sat, Jan 9, 2010 at 7:34 AM, Matt Goodall <matt.goodall@gmail.com> 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
> name.
>
> 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
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>



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

Mime
View raw message