couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cinnebar <>
Subject Re: Initial couchdb accounts feedback
Date Sun, 10 Jan 2010 06:54:33 GMT
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?
our code base is set for 'usr' and would it be not so fun to have to adjust
the erlang there on every couchdb release

i dont follow the logic for using '_users'.

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

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

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

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?


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

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