couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: auth polishing
Date Sun, 17 Jan 2010 09:52:10 GMT
On Sun, Jan 17, 2010 at 1:24 AM, David Goodlad <> wrote:
> On Sun, Jan 17, 2010 at 8:15 PM, Chris Anderson <> wrote:
>> I've also normalized some naming, like user docs to name/password
>> instead of "username" in some places.
> Nice!
>> The /_session response now returns something like:
>> {
>>  userCtx : {
>>    name : "",
>>    roles : ["_admin", "_replicator", "author"]
>>  },
>>  info : {
>>    authentication_db : "_users",
>>    authenticated : ["cookie"],
>>    authentication_handlers : ["oauth", "cookie", "http_basic"]
>>  },
>> }
>> I flirted with the idea of including the userDoc but I'll leave that
>> up to someone else to tackle.
> Including the userDoc is only really useful if convention is going to
> allow devs to add whatever fields they'd like to user docs as far as I
> can tell...

I kinda don't want to press that question too hard yet. I think the
answer is it'll end up a query option to include the doc.

>> TODO:
>> * bcrypt (I think there are some JS implementations out there)
>> * security object (I think this will be a local doc that apps can
>> populate with the help of an admin.)
> +1 for the security object, as we discussed on IRC the other day. I'd
> be happy to see something as simple as the following:
> Validation functions would take a new argument, 'security'. If in the
> database that the validation function is running for there exists a
> document with id '_security', that document would be passed as that
> new argument. The document could have whatever structure a dev felt
> was appropriate, as long as it has the correct id. If there was no
> document, an empty object (or null?) would be passed.

I'm thinking maybe:


where _design/foo is the name of the ddoc that contains the current
validation function.

local means it doesn't replicate. hmm, we also need to make sure the
security doc can only be updated by admins (so maybe _security makes

That's nice and clean:

_security/foo to go with _design/foo

> What is the plan for 'read' permissions, if any? I need to be able to
> grant users read permission on one database but not another...

I have some code open in my editor: couch_db:check_is_admin()

I'm planning to copy this and call it check_is_reader()

So readers is a flat list of names and roles, per db.

If the list is empty, anyone can read. If not, then only readers can
read. A reader is someone who's name or roles matches the db readers
list. This means a private db is just a db where the reader list has
one member, the db-admin.

I think this level of reader ACL is the simplest thing that could
possibly work, and pretty flexible too.

Everything is readable by server admins.

> I appreciate the great work so far Chris!



Chris Anderson

View raw message