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 Sun, 10 Jan 2010 18:19:32 GMT
On Sat, Jan 9, 2010 at 10:54 PM, cinnebar <> wrote:
> big thanks to chris for the improvements to the security
> is there only the single ref to the default account db name in the src?
> and how easy would it be to override the default?

Don't worry, there is no default account name in the source. CouchDB
ships in Admin Party mode before a server admin is configured, so all
clients have admin privileges. This is fine when HTTP access is
restricted to trusted users.

If you're putting your Couch in public all you've got to do is setup
an admin user.

This also means you'll need to give a user account to your http
libraries. They can still use basic auth.

> i dont follow the logic for using '_users'.

the worry is that someone will have an in-house 'users' db. With _ we
don't collide with anyone.

> so id suggest to default users db name to 'usr'  for a few good reasons and
> id put most weight on  _ and e and pluralize are fluff

dgg cl ll try t

> a lot of people like fluff I really dont understand it.
> for me it hurts to hear "i am not an animal i am a javascript function name"
> over and over when sifting through libs
> and then theres impulse to scream in japanese accent "tetsuo !!" whenever i
> accidentlally look at a bit of java.

"i am not an animal i am a javascript function name"

I feel your pain.

> i could go on about why three letter names for core keys/names are serious
> good and a bunch of other reasons why we are using 'usr' here...
> but id say i am in a minority on this point so if the default for the name
> of the users db is easy to override then no sweat really i guess...

you can override the db name by setting

authentication_db = usr

in your local.ini

> also id like to know if there is a way to overide 'roles', i havent had a
> look at the code, we are using 'cat' (as in category) and its a convention
> across all the documents in out datastores... in our 'usr' docs the "cat"
> key does the same thing as "roles" does in chris's screencast and in other
> docsets it keys to values that are roughly equivalent to the way i have seen
> other couchdb users using "type" basically because it seems a bit confusing
> for example to say the couchdb is duck typed then go and map a docset by
> "type" and "cat" is a bit shorter...

overriding "roles" would involve a nasty code change. I don't think
it's worth it.

> in the screencast the "type" key had a "user" value.  is "type" hard coded
> in the users db and if it is what are the other possible values?

right now the only documents allowed are of type "user". I originally
had it set to be more open, but I think it's better to treat this db
more strictly.

> cheers
> On Sun, Jan 10, 2010 at 2:09 PM, Chris Anderson <> wrote:
>> On Sat, Jan 9, 2010 at 1:19 PM, David Goodlad <> wrote:
>> > On Sun, Jan 10, 2010 at 6:22 AM, Matteo Caprari
>> > <> wrote:
>> >> 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.
>> >
>> > I had a bit of a think about this overnight (since I'll be running in
>> > this scenario). If there are dbs that shouldn't share users, perhaps
>> > you could prefix the role with the appname. ie: { roles:
>> > ["myapp1:editor"] }. Then once there are reader ACLs, you could test
>> > that the user included roles with the appropriate prefix.
>> >
>> There's something Damien suggested that I think answers this problem
>> and some of those Brian Candler raised.
>> Currently the validation function takes 3 arguments (newDoc, diskDoc,
>> userCtx)
>> The plan is to add a 4th argument, which is a security object. It
>> would be per-app, and could allow a site (I'm thinking an office or
>> some other organization) to map from site-roles to app-roles. So in
>> the case of a hospital, you'd set up a mapping between various site
>> roles like R.N., M.D., orderly, etc, and application roles
>> (prescription-writer, prescription-filler, etc in the prescription
>> app.)
>> I'm not sure if this gets us 100% of the way there, but I think it
>> gets us at least 80%, without being too complicated.
>> Chris
>> > Now that I've given some more thought to this problem, I've come to
>> > the conclusion that if I implement my roles properly reader ACLs can
>> > handle every case that I've been able to come up with.
>> >
>> > Dave
>> >
>> --
>> Chris Anderson

Chris Anderson

View raw message