couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goodlad <>
Subject Re: auth polishing
Date Sun, 17 Jan 2010 09:24:57 GMT
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.


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

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

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 appreciate the great work so far Chris!


View raw message